public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: Hinko Kocevar <hinko.kocevar@iskramedical.si>
To: Kris Warkentin <kewarken@qnx.com>
Cc: gdb@sources.redhat.com
Subject: Re: remote debugging and source files
Date: Wed, 25 Aug 2004 13:58:00 -0000	[thread overview]
Message-ID: <412C9AFC.70608@iskramedical.si> (raw)
In-Reply-To: <412B82CB.4000503@qnx.com>

Kris Warkentin wrote:
> Hmm...according to your info shared, you have the loader here:
> 
> 0x40001460  0x40011914  No 
> /opt/arm-linux/gcc-3.3.3-glibc-2.3.2/arm-softfloat-linux-gnu/lib/ld-linux.so.2 
> 
> 
> so the breakpoint doesn't seem entirely unreasonable.  Is there any 
> possibility that you have a different ld-linux.so.2 on the host and 
> target? 

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?

If debugging host application debugger stops on dynamic library load as 
expected and 'info shared' says
(gdb) info sharedlibrary
 From        To          Syms Read   Shared Object Library
0x40034680  0x400aadb4  Yes         /usr/X11R6/lib/libX11.so.6
0x40134b40  0x4022f7b4  Yes         /lib/i686/libc.so.6
0x40252eb0  0x40253de4  Yes         /lib/libdl.so.2
0x40000c00  0x400139ef  Yes         /lib/ld-linux.so.2

> Then gdb would be calculating the breakpoint incorrectly based 
> on the host loader.  If you take a look at /usr/include/link.h, you'll 
> find the r_debug structure.  The comments in there will help you 
> calculate the breakpoint by hand (look at the r_brk element) and then 
> you can compare it to what gdb is coming up with.
> 

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?


regards,
h

-- 
hinko <dot> kocevar <at> iskramedical <dot> si
Hinko Kocevar, developer
Iskra Medical d.o.o., Stegne 23, 1k LJ, SLO-EU

	"Aì rén"	|	[Analects XII:22]

  reply	other threads:[~2004-08-25 13:58 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-08-24 14:05 Hinko Kocevar
2004-08-24 15:34 ` Hinko Kocevar
2004-08-24 15:56   ` Hinko Kocevar
2004-08-24 16:35     ` Kris Warkentin
2004-08-24 17:42       ` Hinko Kocevar
2004-08-24 17:53         ` Daniel Jacobowitz
2004-08-24 18:05         ` Kris Warkentin
2004-08-25 13:58           ` Hinko Kocevar [this message]
2004-08-25 14:16             ` Daniel Jacobowitz
2004-08-25 14:30               ` Hinko Kocevar
2004-08-26 19:38                 ` remote debugging and source files - SOLVED Hinko Kocevar
2004-08-25 14:33             ` remote debugging and source files Kris Warkentin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=412C9AFC.70608@iskramedical.si \
    --to=hinko.kocevar@iskramedical.si \
    --cc=gdb@sources.redhat.com \
    --cc=kewarken@qnx.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).