From: Andrew Stubbs <ams@codesourcery.com>
To: gdb@sourceware.org
Subject: debug problem with prelinked libraries
Date: Wed, 05 May 2010 12:48:00 -0000 [thread overview]
Message-ID: <4BE16915.7080501@codesourcery.com> (raw)
Hi all,
I'm trying to get to the bottom of a problem debugging prelinked
libraries. I've fixed a few aspects of the problem, but the further I
get into it the more I think I must be missing something. I mean,
debugging prelinked libraries is supposed to Just Work, right? But I
can't see how it could ever have worked.
First, I should say that I'm trying to debug a core dump that includes
prelinked libraries. Is that different somehow? The target is mips, if
that makes any difference. Also, debugging works fine for the
non-prelinked libraries and core file, so the problem's not there.
I originally encountered the problem with (a somewhat patched)
6.6.50_20070925, but I'm seeing exactly the same trouble in the latest
from CVS.
The problem is that GDB does not find the symbols and debug info for the
code in the prelinked libraries.
Upon closer inspection, I find that the psymtab has the textlow and
texthigh addresses as the original file-offsets, before relocation. This
appears to be because it calculates the section offset as the difference
between the actual address and the ELF VMA, but the file is prelinked,
so the offset is zero, and the debug info and symbols are then not
relocated.
So, I inserted a little code to fixup the offset in the psymtab for the
prelinked cases, but it now loads the symtab with exactly the same
offset troubles. So, I try to fix those, and the problem just moves one
step further on. Surely I can't need to implement prelink support from
scratch, so I must be missing something?
Is there one place that this should be fixed? I think I need to adjust
the base address used by the debug info, but I don't know how to do it
without also changing the base address used for relocating the binaries.
Any other suggestions? Any help would be much appreciated.
Andrew
next reply other threads:[~2010-05-05 12:48 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-05 12:48 Andrew Stubbs [this message]
2010-05-05 14:35 ` Daniel Jacobowitz
2010-05-05 14:59 ` Andrew Stubbs
2010-05-07 13:23 ` Jan Kratochvil
2010-05-07 13:26 ` Andrew Stubbs
2010-07-01 15:43 ` Thomas Schwinge
2010-07-06 9:59 ` MIPS: 64-bit DWARF (was: debug problem with prelinked libraries) Thomas Schwinge
2010-07-14 8:50 ` MIPS: 64-bit DWARF Thomas Schwinge
2010-07-14 16:56 ` David Daney
2010-07-14 18:44 ` Maciej W. Rozycki
2010-07-15 15:48 ` Tom Tromey
2010-07-16 14:44 ` Maciej W. Rozycki
2010-07-21 22:54 ` Joseph S. Myers
2010-07-22 5:28 ` Tom Tromey
2010-07-16 11:22 ` Thomas Schwinge
2010-07-19 20:00 ` Richard Sandiford
2010-07-22 7:41 ` Thomas Schwinge
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=4BE16915.7080501@codesourcery.com \
--to=ams@codesourcery.com \
--cc=gdb@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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).