From: Thomas Schwinge <thomas@codesourcery.com>
To: binutils@sourceware.org
Cc: Jan Kratochvil <jan.kratochvil@redhat.com>,
Andrew Stubbs <ams@codesourcery.com>,
gdb@sourceware.org, macro@codesourcery.com,
nathan@codesourcery.com
Subject: Re: MIPS: 64-bit DWARF
Date: Wed, 14 Jul 2010 08:50:00 -0000 [thread overview]
Message-ID: <87eif6v450.fsf@dirichlet.schwinge.homeip.net> (raw)
In-Reply-To: <87fwzxvslw.fsf_-_@dirichlet.schwinge.homeip.net> (Thomas Schwinge's message of "Tue, 06 Jul 2010 11:59:07 +0200")
[-- Attachment #1: Type: text/plain, Size: 4852 bytes --]
Hello!
This is about switching MIPS from 64-bit to 32-bit DWARF format (as other
architectures are doing), for the benefit of prelink.
On 2010-07-06 09:59, I wrote:
> On 2010-07-01 15:43, I wrote:
>> On 2010-05-07 13:23, Jan Kratochvil wrote:
>>> On Wed, 05 May 2010 16:59:36 +0200, Andrew Stubbs wrote:
>>>> > prelink includes code to manipulate the contents of the debug info.
>>> [...]
>>>> Maybe prelink has failed to relocate the debug info in this case?
>>>
>>> The attached patch should fix it.
>>>
>>> Although SHT_MIPS_DWARF value should be recognized only for e_machine as
>>> EM_MIPS or EM_MIPS_RS3_LE or EM_MIPS_X? Or are there some other rules?
>>
>>> --- prelink/src/dso.c-orig 2010-04-13 16:41:15.000000000 +0200
>>> +++ prelink/src/dso.c 2010-05-07 15:16:25.000000000 +0200
>>> @@ -1381,6 +1381,7 @@ adjust_dso (DSO *dso, GElf_Addr start, G
>>> switch (dso->shdr[i].sh_type)
>>> {
>>> case SHT_PROGBITS:
>>> + case SHT_MIPS_DWARF:
>>> name = strptr (dso, dso->ehdr.e_shstrndx, dso->shdr[i].sh_name);
>>> if (strcmp (name, ".stab") == 0
>>> && adjust_stabs (dso, i, start, adjust))
>>
>> Unfortunately, this patch causes the following regression for about every
>> test of the prelink testsuite, in -mabi=64 configurations (only):
>>
>> mips-wrs-linux-gnu-prelink -c ./prelink.conf -C ./prelink.cache --ld-library-path=. --dynamic-linker=./ld.so.1 -vm ./reloc1
>> Laying out 4 libraries in virtual address space 0000005800000000-0000009800000000
>> Assigned virtual address space slots for libraries:
>> ./ld.so.1 0000005800000000-0000005800032328
>> ./libc.so.6 0000005800040000-00000058001cbdb0
>> ./reloc1lib1.so 00000058001d0000-00000058001e0b10
>> ./reloc1lib2.so 00000058001f0000-00000058002009d0
>> Prelinking /scratch/thomas/issue8927/obj/test-4.3a-294-mips-wrs-linux-gnu/host-i686-pc-linux-gnu/mabi_64/prelink.d/ld-2.8.so
>> mips-wrs-linux-gnu-prelink: /scratch/thomas/issue8927/obj/test-4.3a-294-mips-wrs-linux-gnu/host-i686-pc-linux-gnu/mabi_64/prelink.d/ld-2.8.so: 64-bit DWARF not supported
>
> This happens when processing .debug_lines, which is generated by GAS.
>
> prelink does not support the 64-bit DWARF format. From a quick glance,
> GDB does, see dwarf2read.c:read_initial_length.
>
> MIPS is, per gas/config/tc-mips, the only architecture to override
> DWARF2_FORMAT (which defaults to 32-bit), and thus possibly can emit
> 64-bit DWARF code, which it actually does for -mabi=64, see
> tc-mips.c:mips_dwarf2_format.
>
> In <http://sourceware.org/ml/binutils/2002-11/msg00429.html> this 64-bit
> DWARF format support has originally been added.
>
> What's our way forward? Can we switch MIPS back to only using the 32-bit
> DWARF format (save the IRIX case)? Do we need to extend prelink?
>
> As I understand the GCC code, it always uses the 32-bit DWARF format,
> even for MIPS 64-bit ABIs.
Here is the patch that I tested for (a non-HEAD version of) binutils.
This makes prelink happy, and there are no regressions in the GDB
testsuite. (Anything else to test?) I left in the 64-bit stuff for
TE_IRIX, as I have no idea about it.
Index: gas/config/tc-mips.c
===================================================================
--- gas/config/tc-mips.c (revision 291480)
+++ gas/config/tc-mips.c (working copy)
@@ -15499,20 +15499,16 @@
#endif
}
+#ifdef TE_IRIX
enum dwarf2_format
mips_dwarf2_format (void)
{
if (HAVE_64BIT_SYMBOLS)
- {
-#ifdef TE_IRIX
- return dwarf2_format_64bit_irix;
-#else
- return dwarf2_format_64bit;
-#endif
- }
+ return dwarf2_format_64bit_irix;
else
return dwarf2_format_32bit;
}
+#endif
int
mips_dwarf2_addr_size (void)
Index: gas/config/tc-mips.h
===================================================================
--- gas/config/tc-mips.h (revision 291480)
+++ gas/config/tc-mips.h (working copy)
@@ -165,9 +165,13 @@
extern void mips_enable_auto_align (void);
#define md_elf_section_change_hook() mips_enable_auto_align()
+#ifdef TE_IRIX
enum dwarf2_format;
extern enum dwarf2_format mips_dwarf2_format (void);
-#define DWARF2_FORMAT() mips_dwarf2_format ()
+# define DWARF2_FORMAT() mips_dwarf2_format ()
+#else
+/* Use GAS' defaults. */
+#endif
extern int mips_dwarf2_addr_size (void);
#define DWARF2_ADDR_SIZE(bfd) mips_dwarf2_addr_size ()
Is this approach OK, or is there a real reason to have 64-bit DWARF
format on MIPS? If it's OK, then I'll port the patch to binutils HEAD
((unused) asection * added to DWARF2_FORMAT).
Regards,
Thomas
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
next prev parent reply other threads:[~2010-07-14 8:50 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-05 12:48 debug problem with prelinked libraries Andrew Stubbs
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 ` Thomas Schwinge [this message]
2010-07-14 16:56 ` MIPS: 64-bit DWARF 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=87eif6v450.fsf@dirichlet.schwinge.homeip.net \
--to=thomas@codesourcery.com \
--cc=ams@codesourcery.com \
--cc=binutils@sourceware.org \
--cc=gdb@sourceware.org \
--cc=jan.kratochvil@redhat.com \
--cc=macro@codesourcery.com \
--cc=nathan@codesourcery.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).