* linking elf notes together on elf32-arm
@ 2011-07-06 23:19 Mark Wielaard
2011-07-12 23:01 ` Nick Clifton
0 siblings, 1 reply; 2+ messages in thread
From: Mark Wielaard @ 2011-07-06 23:19 UTC (permalink / raw)
To: binutils; +Cc: Stan Cox, Nick Clifton
Hi,
While trying to build a program that uses sdt elf notes on an elf32-arm
architecture I get the following error on the final link:
/usr/bin/ld: staprun-util.o: duplicate section `.note.stapsdt' has
different size
The different object files do have different sized note sections,
because they contain different things and so shouldn't be merged
together as duplicates.
This is because all elf notes are marked as link once in
bfd/elf32-arm.c:
/* Set the right machine number for an Arm ELF file. */
static bfd_boolean
elf32_arm_section_flags (flags, hdr)
flagword *flags;
Elf_Internal_Shdr *hdr;
{
if (hdr->sh_type == SHT_NOTE)
*flags |= SEC_LINK_ONCE | SEC_LINK_DUPLICATES_SAME_CONTENTS;
return TRUE;
}
That seems wrong to me. Why are all SHT_NOTE sections treated that way?
Should it be just some specific arm named ones?
It seems to have been introduced a long time ago:
2003-03-25 Stan Cox <scox@redhat.com>
Nick Clifton <nickc@redhat.com>
Contribute support for Intel's iWMMXt chip - an ARM variant:
[...]
(elf32_arm_section_flags): New function: Set flags on note section.
Can anybody remember why that was, and how to make it so that "normal"
elf notes don't get merged?
Thanks,
Mark
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: linking elf notes together on elf32-arm
2011-07-06 23:19 linking elf notes together on elf32-arm Mark Wielaard
@ 2011-07-12 23:01 ` Nick Clifton
0 siblings, 0 replies; 2+ messages in thread
From: Nick Clifton @ 2011-07-12 23:01 UTC (permalink / raw)
To: Mark Wielaard; +Cc: binutils, Stan Cox
Hi Mark,
> static bfd_boolean
> elf32_arm_section_flags (flags, hdr)
> flagword *flags;
> Elf_Internal_Shdr *hdr;
> {
> if (hdr->sh_type == SHT_NOTE)
> *flags |= SEC_LINK_ONCE | SEC_LINK_DUPLICATES_SAME_CONTENTS;
This is a snafu. It is left over from some old code which used to store
ARM attributes in a note section. It is no longer needed, so I am going
to check in the patch below to remove it.
Cheers
Nick
bfd/ChangeLog
2011-07-12 Nick Clifton <nickc@redhat.com>
* elf32-arm.c (elf32_arm_section_flags): Delete.
(elf_backend_section_flags): Remove.
Index: bfd/elf32-arm.c
===================================================================
RCS file: /cvs/src/src/bfd/elf32-arm.c,v
retrieving revision 1.272
diff -u -3 -p -r1.272 elf32-arm.c
--- bfd/elf32-arm.c 22 Jun 2011 16:06:00 -0000 1.272
+++ bfd/elf32-arm.c 12 Jul 2011 15:15:51 -0000
@@ -14101,17 +14101,6 @@ elf32_arm_reloc_type_class (const Elf_In
}
}
-/* Set the right machine number for an Arm ELF file. */
-
-static bfd_boolean
-elf32_arm_section_flags (flagword *flags, const Elf_Internal_Shdr *hdr)
-{
- if (hdr->sh_type == SHT_NOTE)
- *flags |= SEC_LINK_ONCE | SEC_LINK_DUPLICATES_SAME_CONTENTS;
-
- return TRUE;
-}
-
static void
elf32_arm_final_write_processing (bfd *abfd, bfd_boolean linker
ATTRIBUTE_UNUSED)
{
@@ -15337,7 +15326,6 @@ const struct elf_size_info elf32_arm_siz
#define elf_backend_post_process_headers elf32_arm_post_process_headers
#define elf_backend_reloc_type_class elf32_arm_reloc_type_class
#define elf_backend_object_p elf32_arm_object_p
-#define elf_backend_section_flags elf32_arm_section_flags
#define elf_backend_fake_sections elf32_arm_fake_sections
#define elf_backend_section_from_shdr elf32_arm_section_from_shdr
#define elf_backend_final_write_processing
elf32_arm_final_write_processing
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2011-07-12 15:17 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-07-06 23:19 linking elf notes together on elf32-arm Mark Wielaard
2011-07-12 23:01 ` Nick Clifton
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).