From: "Mike Bland" <mbland@google.com>
To: binutils@sourceware.org
Cc: iant@google.com
Subject: _bfd_elf_init_private_section_data setting output section type improperly for .stabstr
Date: Thu, 11 May 2006 12:24:00 -0000 [thread overview]
Message-ID: <8b10c78c0605102132p5d7c9403x176fcc760aade19a@mail.google.com> (raw)
I've a small patch for a bug I believe I've found in the binutils/ld
mainline. I stumbled across it when trying to build and prelink a
libc-2.3.2.so containing .stab and .stabstr sections.
Long and short of it, an update to this conditional in
_bfd_elf_init_private_section_data was causing the section type of
.stabstr to get set to SHT_PROGBITS, when it should have been
SHT_STRTAB. This caused assign_section_numbers to fail to process
.stabstr as SHT_PROGBITS, causing the .stab section to get output with
a sh_entsize of zero. This, in turn, triggered an assertion in the
prelink tool:
prelink: stabs.c:100: adjust_stabs: Assertion `dso->shdr[n].sh_entsize
== 12' failed.
This patch passes all current bintuils test cases. My new test case
fails with the original _bfd_elf_init_private_section_data, and passes
with the new change.
Hope this is in an acceptable format; let me know if there are any
problems, questions, concerns, etc.
Thanks,
Mike
==== src/bfd/elf.c#3 - src/bfd/elf.c ====
--- src/bfd/elf.c#3 2006-05-10 21:10:55.000000000 -0700
+++ src/bfd/elf.c 2006-05-10 19:52:30.000000000 -0700
@@ -6054,7 +6054,8 @@ _bfd_elf_init_private_section_data (bfd
output BFD section flags has been set to something different.
elf_fake_sections will set ELF section type based on BFD
section flags. */
- if (osec->flags == isec->flags || !osec->flags)
+ if (osec->flags == isec->flags
+ || (!osec->flags && elf_section_type (osec) == SHT_NULL))
elf_section_type (osec) = elf_section_type (isec);
/* Set things up for objcopy and relocatable link. The output
==== (added) src/ld/testsuite/ld-elf/stab.d ====
--- /dev/null 2006-04-17 10:27:56.868292750 -0700
+++ src/ld/testsuite/ld-elf/stab.d 2006-05-10 19:53:55.000000000 -0700
@@ -0,0 +1,12 @@
+#source: start.s
+#as: -gstabs
+#readelf: -N
+#ld:
+
+#...
+ \[[0-9 ][0-9]\] \.stab
+ PROGBITS 00000000 0000[0-9a-f][0-9a-f]
0000[0-9a-f][0-9a-f] 0c [1-9]+ 0 4
+#...
+ \[[0-9 ][0-9]\] \.stabstr
+ STRTAB 00000000 0000[0-9a-f][0-9a-f]
0000[0-9a-f][0-9a-f] 00 0 0 1
+#...
next reply other threads:[~2006-05-11 4:32 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-05-11 12:24 Mike Bland [this message]
2006-05-11 15:55 ` Alan Modra
2006-05-11 22:21 ` H. J. Lu
2006-05-11 23:18 ` H. J. Lu
2006-05-12 2:14 ` Ian Lance Taylor
2006-05-15 9:32 ` H. J. Lu
2006-06-01 4:02 ` Alan Modra
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=8b10c78c0605102132p5d7c9403x176fcc760aade19a@mail.google.com \
--to=mbland@google.com \
--cc=binutils@sourceware.org \
--cc=iant@google.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).