Re: remote debugging and source files

[Kris Warkentin <kewarken@qnx.com>]

Hinko Kocevar wrote:

> It is same version on the host and on the target - glibc-2.3.2., but 
> the one on target is cross compiled for ARM architecture, though. Is 
> there any other kind of difference we are interested here?

No, what I mean is that gdb loads the arm binaries from the host.  Those 
binaries need to be the same binaries as the target is running.

>
> Sounds easy, but to me, it is not - at all :).
> OK, here goes...
> I did 'maintenance info breakpoints' while debugging native app:
> ...
> -16 shlib events   keep y   0x4000dd60 <_dl_debug_state_internal>
>         breakpoint already hit 3 times
> ...
>
> So debugger stoped on shared library event 3 times (three dynamic libs 
> were loaded) at <_dl_debug_state_internal> symbol found in 
> ld-2.3.2.so. Using objdump I got the same offset, 0x0000dd60, for 
> _dl_debug_state_internal.
>
> On ARM target using the same technique, shlib events are at 0x4000b8d8 
> while arm-linux-objdump says that _dl_debug_state_internal is at 
> offset 0x0000c258. After setting breakpoint to 0x0000c258 debugger 
> stopped 7 times (according to comments around r_debug that is OK) 
> before my app was stated.
>
> Offset 0x0000b8d8 is location in _dl_signal_error.
>
> So how do I convince gdb to use correct address for shlib event?


At this stage I'm beginning to get confused about which binaries are 
being discussed here since you're comparing the native version with the 
remote.  What I need to verify first is whether or not the ARM binaries 
(libs and app) on the host are EXACTLY the same as the binaries on the 
target.  Then we need to verify that gdb is finding the correct ones.  
If all that is true and it's still not working, then we may need to dig 
deeper into why the solib breakpoint is being calculated incorrectly.  
Can you verify that auto-solib-add is on as well?

cheers,

Kris