* [GOLD][ARM] non-linked ARM EXIDX sections
@ 2010-02-11 0:13 Viktor Kutuzov
2010-02-11 0:20 ` Doug Kwan (關振德)
0 siblings, 1 reply; 2+ messages in thread
From: Viktor Kutuzov @ 2010-02-11 0:13 UTC (permalink / raw)
To: Doug Kwan (關振德); +Cc: binutils
[-- Attachment #1: Type: text/plain, Size: 666 bytes --]
Hi Doug,
I got the problem with the ARM EXIDX sections, when I built the glibc
library. So, there is some object files during a build of glibc, which
contain the non-linked EXIDX sections (without linked text segment).
GOLD fires an error in this situation like this --
error: EXIDX section 9 in /opt/crosstool/build-gold/work/obj.glibc/elf/
librtld.os has no linked text section
but LD links those files without any problems. I have checked out how LD
handles it and I found that LD just skips that kind of EXIDX sections
silently. I suppose, we should do the same thing in GOLD. What do you
think? Something like as it proposed in the attached file.
-Viktor.
[-- Attachment #2: binutils-gold-arm-skip_non_linked_exidx_sections.diff --]
[-- Type: text/x-patch, Size: 1490 bytes --]
Index: arm.cc
===================================================================
RCS file: /cvs/src/src/gold/arm.cc,v
retrieving revision 1.79
diff -u -p -r1.79 arm.cc
--- arm.cc 9 Feb 2010 20:29:44 -0000 1.79
+++ arm.cc 10 Feb 2010 23:48:45 -0000
@@ -5436,6 +5436,11 @@ Arm_output_section<big_endian>::fix_exid
Arm_relobj<big_endian>::as_arm_relobj(p->relobj());
const Arm_exidx_input_section* exidx_input_section =
arm_relobj->exidx_input_section_by_shndx(p->shndx());
+ if (exidx_input_section == NULL)
+ {
+ p->relobj()->set_output_section(p->shndx(), NULL);
+ continue;
+ }
gold_assert(exidx_input_section != NULL);
unsigned int text_shndx = exidx_input_section->link();
gold_assert(symtab->is_section_folded(p->relobj(), text_shndx));
@@ -5972,14 +5977,9 @@ Arm_relobj<big_endian>::make_exidx_input
// Link .text section to its .ARM.exidx section in the same object.
unsigned int text_shndx = this->adjust_shndx(shdr.get_sh_link());
- // Issue an error and ignore this EXIDX section if it does not point
- // to any text section.
+ // Ignore this EXIDX section if it does not point to any text section.
if (text_shndx == elfcpp::SHN_UNDEF)
- {
- gold_error(_("EXIDX section %u in %s has no linked text section"),
- shndx, this->name().c_str());
- return;
- }
+ return;
// Issue an error and ignore this EXIDX section if it points to a text
// section already has an EXIDX section.
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [GOLD][ARM] non-linked ARM EXIDX sections
2010-02-11 0:13 [GOLD][ARM] non-linked ARM EXIDX sections Viktor Kutuzov
@ 2010-02-11 0:20 ` Doug Kwan (關振德)
0 siblings, 0 replies; 2+ messages in thread
From: Doug Kwan (關振德) @ 2010-02-11 0:20 UTC (permalink / raw)
To: vkutuzov; +Cc: binutils
Can you send me the object file? If a bogus EXIDX section is being
generated, we may still want to know about that and fix it. We may
want to turn this into a warning.
-Doug
2010/2/10 Viktor Kutuzov <vkutuzov@accesssoftek.com>:
> Hi Doug,
>
> I got the problem with the ARM EXIDX sections, when I built the glibc
> library. So, there is some object files during a build of glibc, which
> contain the non-linked EXIDX sections (without linked text segment).
> GOLD fires an error in this situation like this --
>
> error: EXIDX section 9 in /opt/crosstool/build-gold/work/obj.glibc/elf/
> librtld.os has no linked text section
>
> but LD links those files without any problems. I have checked out how LD
> handles it and I found that LD just skips that kind of EXIDX sections
> silently. I suppose, we should do the same thing in GOLD. What do you
> think? Something like as it proposed in the attached file.
>
> -Viktor.
>
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2010-02-11 0:20 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-02-11 0:13 [GOLD][ARM] non-linked ARM EXIDX sections Viktor Kutuzov
2010-02-11 0:20 ` Doug Kwan (關振德)
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).