From: "Ulrich Weigand" <uweigand@de.ibm.com>
To: brobecker@adacore.com (Joel Brobecker)
Cc: gdb-patches@sourceware.org
Subject: Re: [RFA/solib-svr4] use AT_BASE auxiliary entry to compute load base address
Date: Thu, 17 Apr 2008 15:29:00 -0000 [thread overview]
Message-ID: <200804171511.m3HFBc5N021455@d12av02.megacenter.de.ibm.com> (raw)
In-Reply-To: <20070912211805.GF10540@adacore.com> from "Joel Brobecker" at Sep 12, 2007 02:18:05 PM
Joel Brobecker wrote:
> 2007-09-12 Joel Brobecker <brobecker@adacore.com>
>
> * solib-svr4.c: Add include of "auxv.h".
> (enable_break): Use the AT_BASE auxiliary entry if available.
> * Makefile.in (solib-svr4.o): Update dependencies.
>
> Tested on x86-linux, no regression. Currently testing on sparc-solaris,
> but it's taking a loooong time because sigstep is keeps timing out to
> death. It fixes the issue above, and I'm confident the results will be OK.
It looks like this breaks remote debugging in the presence of prelinking.
The problem is that AT_BASE is set by the kernel to the load bias (i.e.
the difference between the actual load address and the load address as
recorded in the ELF file) of the dynamic interpreter. GDB goes on to
add back the load address from the ELF file, so that looks fine.
However, when doing remote debugging, the ELF file GDB sees may be
different from the ELF file that was used on the remote target. This
happens in particular if a background prelinking job runs from time
to time on the remote system.
GDB used to work correctly in the presence of prelinking anyway,
because for regular shared libraries it detected that mismatch by
comparing the load addresses from the BFD it reads with those
recorded in the dynamic loader's data structures (LM_ADDR_CHECK),
and adjusting its expectations if it detects prelinking.
However, this does not work for enable_break because this function
must work *before* the dynamic loader gets a chance to set up those
data structures.
Any suggestions how this could be fixed?
Thanks,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
Ulrich.Weigand@de.ibm.com
next prev parent reply other threads:[~2008-04-17 15:12 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-12 21:18 Joel Brobecker
2007-09-13 1:02 ` Joel Brobecker
2007-09-16 19:36 ` Daniel Jacobowitz
2007-09-17 19:42 ` Joel Brobecker
2007-09-17 19:49 ` Daniel Jacobowitz
2008-04-17 15:29 ` Ulrich Weigand [this message]
2008-04-17 17:48 ` Daniel Jacobowitz
2008-04-17 21:45 ` Ulrich Weigand
2008-04-17 22:32 ` Daniel Jacobowitz
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=200804171511.m3HFBc5N021455@d12av02.megacenter.de.ibm.com \
--to=uweigand@de.ibm.com \
--cc=brobecker@adacore.com \
--cc=gdb-patches@sourceware.org \
/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