I have drilled down the problem, it is in the kernel somewhere:
On the axis device i'll get this kernel messages:
> plugin of usbdevice
hub.c: new USB device etrax100lx-2, assigned address 4
> we found a Dallas DS2490 USB to ONEWIRE Bridge Chip
> this is ok
usb.c: USB device 4 (vend/prod 0x4fa/0x2490) is not claimed by any active driver.
> first usb_control_msg sent fails to reset the Onwire BUS on the DS2490
usbdevfs: USBDEVFS_BULK failed dev 4 ep 0x2 len 8 ret -110
on the linux host i do NOT get any error, all works fine with Kernel 2.4.19 gcc3.2 !!
Von: Orjan Friberg [mailto:email@example.com]
Gesendet: Mittwoch, 04. Juni 2003 15:52
An: Schachner Thomas
Betreff: Re: AW: AW: problem with gdb-cris
Orjan Friberg wrote:
> Even if your program crashed inside a library function, you should at
> least be able to see that the innermost stack frame. I tried this with
> gdb-cris 5.3, but I'm going to try it with 5.2.1 also.
Ok, it works with 5.2.1 also. If you feel like digging into it, you
could add printouts in elf_core_dump in os/linux/fs/binfmt_elf.c to
print the pt_regs struct, in which the irp member contains the pc. In
case it's in a shared library you'll have to check /proc/<pid>/maps also
to see where each library was loaded. That could give you a clue as to
which function it was in when it crashed.
Do you know if the program ever reaches the main() function? If you get
that far, maybe printfs could be helpful in tracking down where it crashes.