* gc sections and .eh_frame
@ 2005-06-07 17:48 Jonathan Larmour
2005-06-07 18:00 ` Eric Botcazou
2005-06-08 2:09 ` Alan Modra
0 siblings, 2 replies; 50+ messages in thread
From: Jonathan Larmour @ 2005-06-07 17:48 UTC (permalink / raw)
To: binutils
After an update to binutils 2.16 from 2.15 I have found that sections
referenced by .eh_frame with relocs do not get pulled in if linking
(statically) with --gc-sections. Initially I just put a
KEEP(*(.gcc_except_table)) in my ldscript to work round this.
But now I'm using the powerpc architecture where the stuff usually in
.gcc_except_table is placed in .rodata instead. If the object file has
nothing else in .rodata, then that section is also being GC'd in the final
link. And Bad Things Happen.
I believe I have tracked this down to a change enclosed in full at the end
of this mail, made by Eric Botcazou on 2004-04-21. I've looked at the
mailing list archives, and not found any posting or discussion of the
patch, or its rationale. Is that right?
Anyway, the most relevant bit in elflink.c:bfd_elf_gc_sections() is:
for (o = sub->sections; o != NULL; o = o->next)
{
if (o->flags & SEC_KEEP)
- if (!elf_gc_mark (info, o, gc_mark_hook))
- return FALSE;
+ {
+ /* _bfd_elf_discard_section_eh_frame knows how to discard
+ orphaned FDEs so don't mark sections referenced by the
+ EH frame section. */
+ if (strcmp (o->name, ".eh_frame") == 0)
+ o->gc_mark = 1;
+ else if (!elf_gc_mark (info, o, gc_mark_hook))
+ return FALSE;
+ }
}
}
This change doesn't make sense to me. _bfd_elf_discard_section_eh_frame
does not set gc_mark on any section. So as a result, I would assume none
of the reloc dependencies of .eh_frame would ever get marked and that's
how those sections get GC'd. Am I missing something?
There seems to have been some effort at the time to allow GC of sections
in dynamically linked programs (I think). Perhaps this was a change which
is only relevant for dynamic, not static linking? Certainly from my view,
the correct thing to do is simply revert this part of the change.
Jifl
Index: ChangeLog
===================================================================
RCS file: /cvs/src/src/bfd/ChangeLog,v
retrieving revision 1.2501
retrieving revision 1.2502
diff -u -5 -p -r1.2501 -r1.2502
--- ChangeLog 20 Apr 2004 12:17:12 -0000 1.2501
+++ ChangeLog 21 Apr 2004 07:14:15 -0000 1.2502
@@ -1,5 +1,14 @@
+2004-04-21 Eric Botcazou <ebotcazou@act-europe.fr>
+
+ * elflink.c (elf_gc_mark_dynamic_ref_symbol): New function.
+ (bfd_elf_gc_sections): Fail if a shared object is being created.
+ Do not fail if dynamic sections have been created. Instead call
+ elf_gc_mark_dynamic_ref_symbol to mark sections that contain
+ dynamically referenced symbols. Do not mark the whole graph
+ rooted at .eh_frame, only the section proper.
+
2004-04-20 DJ Delorie <dj@redhat.com>
* reloc.c: Add BFD_RELOC_32_SECREL.
* bfd-in2.h: Regenerate.
* libbfd.h: Likewise.
Index: elflink.c
===================================================================
RCS file: /cvs/src/src/bfd/elflink.c,v
retrieving revision 1.65
retrieving revision 1.66
diff -u -5 -p -r1.65 -r1.66
--- elflink.c 15 Apr 2004 02:55:20 -0000 1.65
+++ elflink.c 21 Apr 2004 07:14:15 -0000 1.66
@@ -8410,10 +8410,28 @@ elf_gc_smash_unused_vtentry_relocs (stru
}
return TRUE;
}
+/* Mark sections containing dynamically referenced symbols. This is called
+ through elf_link_hash_traverse. */
+
+static bfd_boolean
+elf_gc_mark_dynamic_ref_symbol (struct elf_link_hash_entry *h,
+ void *okp ATTRIBUTE_UNUSED)
+{
+ if (h->root.type == bfd_link_hash_warning)
+ h = (struct elf_link_hash_entry *) h->root.u.i.link;
+
+ if ((h->root.type == bfd_link_hash_defined
+ || h->root.type == bfd_link_hash_defweak)
+ && (h->elf_link_hash_flags & ELF_LINK_HASH_REF_DYNAMIC))
+ h->root.u.def.section->flags |= SEC_KEEP;
+
+ return TRUE;
+}
+
/* Do mark and sweep of unused sections. */
bfd_boolean
bfd_elf_gc_sections (bfd *abfd, struct bfd_link_info *info)
{
@@ -8424,12 +8442,12 @@ bfd_elf_gc_sections (bfd *abfd, struct b
struct elf_link_hash_entry *h, Elf_Internal_Sym *);
if (!get_elf_backend_data (abfd)->can_gc_sections
|| info->relocatable
|| info->emitrelocations
- || !is_elf_hash_table (info->hash)
- || elf_hash_table (info)->dynamic_sections_created)
+ || info->shared
+ || !is_elf_hash_table (info->hash))
{
(*_bfd_error_handler)(_("Warning: gc-sections option ignored"));
return TRUE;
}
@@ -8445,12 +8463,19 @@ bfd_elf_gc_sections (bfd *abfd, struct b
elf_gc_smash_unused_vtentry_relocs,
&ok);
if (!ok)
return FALSE;
- /* Grovel through relocs to find out who stays ... */
+ /* Mark dynamically referenced symbols. */
+ if (elf_hash_table (info)->dynamic_sections_created)
+ elf_link_hash_traverse (elf_hash_table (info),
+ elf_gc_mark_dynamic_ref_symbol,
+ &ok);
+ if (!ok)
+ return FALSE;
+ /* Grovel through relocs to find out who stays ... */
gc_mark_hook = get_elf_backend_data (abfd)->gc_mark_hook;
for (sub = info->input_bfds; sub != NULL; sub = sub->link_next)
{
asection *o;
@@ -8458,12 +8483,19 @@ bfd_elf_gc_sections (bfd *abfd, struct b
continue;
for (o = sub->sections; o != NULL; o = o->next)
{
if (o->flags & SEC_KEEP)
- if (!elf_gc_mark (info, o, gc_mark_hook))
- return FALSE;
+ {
+ /* _bfd_elf_discard_section_eh_frame knows how to discard
+ orphaned FDEs so don't mark sections referenced by the
+ EH frame section. */
+ if (strcmp (o->name, ".eh_frame") == 0)
+ o->gc_mark = 1;
+ else if (!elf_gc_mark (info, o, gc_mark_hook))
+ return FALSE;
+ }
}
}
/* ... and mark SEC_EXCLUDE for those that go. */
if (!elf_gc_sweep (info, get_elf_backend_data (abfd)->gc_sweep_hook))
--
eCosCentric http://www.eCosCentric.com/ The eCos and RedBoot experts
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: gc sections and .eh_frame
2005-06-07 17:48 gc sections and .eh_frame Jonathan Larmour
@ 2005-06-07 18:00 ` Eric Botcazou
2005-06-07 18:11 ` Jonathan Larmour
2005-06-08 2:09 ` Alan Modra
1 sibling, 1 reply; 50+ messages in thread
From: Eric Botcazou @ 2005-06-07 18:00 UTC (permalink / raw)
To: Jonathan Larmour; +Cc: binutils
> I believe I have tracked this down to a change enclosed in full at the end
> of this mail, made by Eric Botcazou on 2004-04-21. I've looked at the
> mailing list archives, and not found any posting or discussion of the
> patch, or its rationale. Is that right?
http://sourceware.org/ml/binutils/2004-03/msg00424.html
> Anyway, the most relevant bit in elflink.c:bfd_elf_gc_sections() is:
>
> for (o = sub->sections; o != NULL; o = o->next)
> {
> if (o->flags & SEC_KEEP)
> - if (!elf_gc_mark (info, o, gc_mark_hook))
> - return FALSE;
> + {
> + /* _bfd_elf_discard_section_eh_frame knows how to discard
> + orphaned FDEs so don't mark sections referenced by the
> + EH frame section. */
> + if (strcmp (o->name, ".eh_frame") == 0)
> + o->gc_mark = 1;
> + else if (!elf_gc_mark (info, o, gc_mark_hook))
> + return FALSE;
> + }
> }
> }
>
> This change doesn't make sense to me. _bfd_elf_discard_section_eh_frame
> does not set gc_mark on any section. So as a result, I would assume none
> of the reloc dependencies of .eh_frame would ever get marked and that's
> how those sections get GC'd. Am I missing something?
Presumably:
2004-04-21 Eric Botcazou <ebotcazou@act-europe.fr>
* scripttempl/elf.sc (.text): Add KEEP for .text.*personality*.
(.data): Add KEEP for .gnu.linkonce.d.*personality*.
(.gcc_except_table): Add KEEP for self and accept .gcc_except_table.*.
--
Eric Botcazou
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: gc sections and .eh_frame
2005-06-07 18:00 ` Eric Botcazou
@ 2005-06-07 18:11 ` Jonathan Larmour
0 siblings, 0 replies; 50+ messages in thread
From: Jonathan Larmour @ 2005-06-07 18:11 UTC (permalink / raw)
To: Eric Botcazou; +Cc: binutils
Eric Botcazou wrote:
>Jifl wrote:
>>This change doesn't make sense to me. _bfd_elf_discard_section_eh_frame
>>does not set gc_mark on any section. So as a result, I would assume none
>>of the reloc dependencies of .eh_frame would ever get marked and that's
>>how those sections get GC'd. Am I missing something?
>
>
> Presumably:
>
> 2004-04-21 Eric Botcazou <ebotcazou@act-europe.fr>
>
> * scripttempl/elf.sc (.text): Add KEEP for .text.*personality*.
> (.data): Add KEEP for .gnu.linkonce.d.*personality*.
> (.gcc_except_table): Add KEEP for self and accept .gcc_except_table.*.
>
Yes, as I mentioned briefly that doesn't help for powerpc, where the
referenced data doesn't go in .gcc_except_table, but instead goes in
.rodata. Don't ask me why it does, but it does. Probably some weird ABI thing.
It's also worth mentioning that even on other architectures, this new
requirement (the KEEP) would cause a regression with previously working
builds. And a pretty difficult to diagnose one at that. On embedded
systems, custom linker scripts are exceptionally common. The default GNU
ld template stuff isn't very relevant. For example, have a look at
newlib/libgloss (although I'm using a different runtime). Of course this
would only affect people using --gc-sections with recent binutils, which
is why you probably haven't had people jumping up and down yet :-).
Jifl
--
eCosCentric http://www.eCosCentric.com/ The eCos and RedBoot experts
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: gc sections and .eh_frame
2005-06-07 17:48 gc sections and .eh_frame Jonathan Larmour
2005-06-07 18:00 ` Eric Botcazou
@ 2005-06-08 2:09 ` Alan Modra
2005-06-08 11:13 ` Jonathan Larmour
1 sibling, 1 reply; 50+ messages in thread
From: Alan Modra @ 2005-06-08 2:09 UTC (permalink / raw)
To: Jonathan Larmour; +Cc: binutils
On Tue, Jun 07, 2005 at 06:49:00PM +0100, Jonathan Larmour wrote:
> But now I'm using the powerpc architecture where the stuff usually in
> .gcc_except_table is placed in .rodata instead. If the object file has
> nothing else in .rodata, then that section is also being GC'd in the final
> link. And Bad Things Happen.
Which powerpc target? What compiler version?
--
Alan Modra
IBM OzLabs - Linux Technology Centre
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: gc sections and .eh_frame
2005-06-08 2:09 ` Alan Modra
@ 2005-06-08 11:13 ` Jonathan Larmour
2005-06-08 19:10 ` Richard Henderson
0 siblings, 1 reply; 50+ messages in thread
From: Jonathan Larmour @ 2005-06-08 11:13 UTC (permalink / raw)
To: Alan Modra; +Cc: binutils
Alan Modra wrote:
> On Tue, Jun 07, 2005 at 06:49:00PM +0100, Jonathan Larmour wrote:
>
>>But now I'm using the powerpc architecture where the stuff usually in
>>.gcc_except_table is placed in .rodata instead. If the object file has
>>nothing else in .rodata, then that section is also being GC'd in the final
>>link. And Bad Things Happen.
>
>
> Which powerpc target? What compiler version?
powerpc-eabi, gcc 3.4.4.
From a brief foray into the GCC sources, I believe the use of
gcc_except_table depends on the existence of TARGET_ASM_NAMED_SECTION,
which is not defined for any powerpc other than rs6000-xcoff.
There are probably other targets than powerpc that don't have
TARGET_ASM_NAMED_SECTION too. From a glance, SuperH doesn't either at least.
I still don't have an understanding as to why sections referenced (by
reloc) from .eh_frame shouldn't be kept safe from GC. Marking them as KEEP
in the linker script just means that you've got one bit of code trying to
stop such sections being included, and another bit in the linker script
forcing them to be. It seems pointless and breaks existing working linker
scripts, nevermind the powerpc issue.
Jifl
--
eCosCentric http://www.eCosCentric.com/ The eCos and RedBoot experts
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: gc sections and .eh_frame
2005-06-08 11:13 ` Jonathan Larmour
@ 2005-06-08 19:10 ` Richard Henderson
2005-06-08 19:29 ` Jonathan Larmour
0 siblings, 1 reply; 50+ messages in thread
From: Richard Henderson @ 2005-06-08 19:10 UTC (permalink / raw)
To: Jonathan Larmour; +Cc: Alan Modra, binutils
On Wed, Jun 08, 2005 at 12:14:07PM +0100, Jonathan Larmour wrote:
> From a brief foray into the GCC sources, I believe the use of
> gcc_except_table depends on the existence of TARGET_ASM_NAMED_SECTION,
> which is not defined for any powerpc other than rs6000-xcoff.
You're confused. All elf have it.
r~
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: gc sections and .eh_frame
2005-06-08 19:10 ` Richard Henderson
@ 2005-06-08 19:29 ` Jonathan Larmour
2005-06-08 19:32 ` Richard Henderson
0 siblings, 1 reply; 50+ messages in thread
From: Jonathan Larmour @ 2005-06-08 19:29 UTC (permalink / raw)
To: Richard Henderson; +Cc: Alan Modra, binutils
Richard Henderson wrote:
> On Wed, Jun 08, 2005 at 12:14:07PM +0100, Jonathan Larmour wrote:
>
>From a brief foray into the GCC sources, I believe the use of
>>gcc_except_table depends on the existence of TARGET_ASM_NAMED_SECTION,
>>which is not defined for any powerpc other than rs6000-xcoff.
>
>
> You're confused. All elf have it.
Fair enough, it was only a belief, and it's easy for GCC to confuse me ;).
But empirically, powerpc-eabi does put exception stuff referenced from
.eh_frame into .rodata:
dargo:/tmp$ cat >e.cxx
extern void foo(void);
int main()
{
try {
foo();
} catch(...) {
return 1;
};
return 0;
}
dargo:/tmp$ powerpc-eabi-g++ -c e.cxx
dargo:/tmp$ powerpc-eabi-objdump -h e.o
e.o: file format elf32-powerpc
Sections:
Idx Name Size VMA LMA File off Algn
0 .text 00000060 00000000 00000000 00000034 2**2
CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
1 .data 00000000 00000000 00000000 00000094 2**0
CONTENTS, ALLOC, LOAD, DATA
2 .bss 00000000 00000000 00000000 00000094 2**0
ALLOC
3 .rodata 00000014 00000000 00000000 00000094 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
4 .eh_frame 00000040 00000000 00000000 000000a8 2**2
CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
5 .comment 00000020 00000000 00000000 000000e8 2**0
CONTENTS, READONLY
The .rodata there contains the exception info referenced by .eh_frame and
there is no .gcc_except_table section present at all.
This has been the case for years for powerpc-eabi, I don't know how long.
Jifl
--
eCosCentric http://www.eCosCentric.com/ The eCos and RedBoot experts
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: gc sections and .eh_frame
2005-06-08 19:29 ` Jonathan Larmour
@ 2005-06-08 19:32 ` Richard Henderson
2005-06-08 21:36 ` Jonathan Larmour
0 siblings, 1 reply; 50+ messages in thread
From: Richard Henderson @ 2005-06-08 19:32 UTC (permalink / raw)
To: Jonathan Larmour; +Cc: Alan Modra, binutils
On Wed, Jun 08, 2005 at 08:30:34PM +0100, Jonathan Larmour wrote:
> But empirically, powerpc-eabi does put exception stuff referenced from
> .eh_frame into .rodata:
Which is correct, that's where it belongs.
> there is no .gcc_except_table section present at all.
This is, and has always been, created by the linker.
r~
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: gc sections and .eh_frame
2005-06-08 19:32 ` Richard Henderson
@ 2005-06-08 21:36 ` Jonathan Larmour
2005-06-08 22:02 ` Richard Henderson
0 siblings, 1 reply; 50+ messages in thread
From: Jonathan Larmour @ 2005-06-08 21:36 UTC (permalink / raw)
To: Richard Henderson; +Cc: Alan Modra, binutils
Richard Henderson wrote:
> On Wed, Jun 08, 2005 at 08:30:34PM +0100, Jonathan Larmour wrote:
>
>>But empirically, powerpc-eabi does put exception stuff referenced from
>>.eh_frame into .rodata:
>
>
> Which is correct, that's where it belongs.
>
>
>>there is no .gcc_except_table section present at all.
>
>
> This is, and has always been, created by the linker.
Now I'm really confused:
dargo:/tmp$ arm-elf-g++ -c e.cxx
dargo:/tmp$ arm-elf-objdump -h e.o
e.o: file format elf32-littlearm
Sections:
Idx Name Size VMA LMA File off Algn
0 .text 000000a8 00000000 00000000 00000034 2**2
CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
1 .data 00000000 00000000 00000000 000000dc 2**0
CONTENTS, ALLOC, LOAD, DATA
2 .bss 00000000 00000000 00000000 000000dc 2**0
ALLOC
3 .gcc_except_table 00000010 00000000 00000000 000000dc 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
4 .comment 00000020 00000000 00000000 000000ec 2**0
CONTENTS, READONLY
dargo:/tmp$ i386-elf-g++ -c e.cxx
dargo:/tmp$ i386-elf-objdump -h e.o
e.o: file format elf32-i386
Sections:
Idx Name Size VMA LMA File off Algn
0 .text 00000049 00000000 00000000 00000034 2**2
CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
1 .data 00000000 00000000 00000000 00000080 2**2
CONTENTS, ALLOC, LOAD, DATA
2 .bss 00000000 00000000 00000000 00000080 2**2
ALLOC
3 .gcc_except_table 00000014 00000000 00000000 00000080 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
4 .eh_frame 00000040 00000000 00000000 00000094 2**2
CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
5 .comment 00000020 00000000 00000000 000000d4 2**0
CONTENTS, READONLY
dargo:/tmp$ m68k-elf-g++ -c e.cxx
dargo:/tmp$ m68k-elf-objdump -h e.o
e.o: file format elf32-m68k
Sections:
Idx Name Size VMA LMA File off Algn
0 .text 00000030 00000000 00000000 00000034 2**2
CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
1 .data 00000000 00000000 00000000 00000064 2**2
CONTENTS, ALLOC, LOAD, DATA
2 .bss 00000000 00000000 00000000 00000064 2**2
ALLOC
3 .gcc_except_table 00000014 00000000 00000000 00000064 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
4 .eh_frame 00000040 00000000 00000000 00000078 2**2
CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
5 .comment 00000020 00000000 00000000 000000b8 2**0
CONTENTS, READONLY
dargo:/tmp$ mipsisa32-elf-g++ -c e.cxx
dargo:/tmp$ mipsisa32-elf-objdump -h e.o
e.o: file format elf32-bigmips
Sections:
Idx Name Size VMA LMA File off Algn
0 .text 00000068 00000000 00000000 00000034 2**2
CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
1 .data 00000000 00000000 00000000 0000009c 2**0
CONTENTS, ALLOC, LOAD, DATA
2 .bss 00000000 00000000 00000000 0000009c 2**0
ALLOC
3 .reginfo 00000018 00000000 00000000 0000009c 2**2
CONTENTS, READONLY, LINK_ONCE_SAME_SIZE
4 .pdr 00000020 00000000 00000000 000000b4 2**2
CONTENTS, RELOC, READONLY
5 .mdebug.eabi32 00000000 00000000 00000000 000000d4 2**0
CONTENTS, READONLY
6 .gcc_except_table 00000014 00000000 00000000 000000d4 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
7 .eh_frame 00000040 00000000 00000000 000000e8 2**2
CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
and so on.
Are the powerpc-eabi tools the only ones behaving correctly (putting it in
.rodata) and all the others wrong?
Jifl
--
eCosCentric http://www.eCosCentric.com/ The eCos and RedBoot experts
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: gc sections and .eh_frame
2005-06-08 21:36 ` Jonathan Larmour
@ 2005-06-08 22:02 ` Richard Henderson
2005-06-09 10:33 ` Jonathan Larmour
0 siblings, 1 reply; 50+ messages in thread
From: Richard Henderson @ 2005-06-08 22:02 UTC (permalink / raw)
To: Jonathan Larmour; +Cc: Alan Modra, binutils
On Wed, Jun 08, 2005 at 10:36:11PM +0100, Jonathan Larmour wrote:
> >>there is no .gcc_except_table section present at all.
> >
> >This is, and has always been, created by the linker.
Sorry, I was thinking of .eh_frame_hdr.
> Are the powerpc-eabi tools the only ones behaving correctly (putting it in
> .rodata) and all the others wrong?
*shrug* I'm not sure why ppc-eabi is the only one different.
Probably just an oversight somewhere in the rs6000 port.
r~
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: gc sections and .eh_frame
2005-06-08 22:02 ` Richard Henderson
@ 2005-06-09 10:33 ` Jonathan Larmour
2005-06-09 11:38 ` Eric Botcazou
0 siblings, 1 reply; 50+ messages in thread
From: Jonathan Larmour @ 2005-06-09 10:33 UTC (permalink / raw)
To: binutils
Richard Henderson wrote:
> On Wed, Jun 08, 2005 at 10:36:11PM +0100, Jonathan Larmour wrote:
>>Are the powerpc-eabi tools the only ones behaving correctly (putting it in
>>.rodata) and all the others wrong?
>
> *shrug* I'm not sure why ppc-eabi is the only one different.
> Probably just an oversight somewhere in the rs6000 port.
Or could be an ABI thing. I don't know. But I don't think that's relevant
as that clearly is the way it has worked for a long time (probably
forever), and the elflink.c change in question breaks it. Also as I
mentioned (but I don't care as much about personally as I'm now
unaffected), the change breaks existing linker scripts much more widely
than powerpc-eabi.
So far, no-one has given any rationalisation for the change. It wasn't
posted to this list, so there's no reason given there. To my eye, the
change doesn't seem right - if a section is a dependency of .eh_frame, it
needs to be kept. Needing to forcibly KEEP() all .gcc_except_table
sections should not have been necessary in the first place.
There may well be a very good reason for the change that I'm not aware of
or am too dumb to see. That's entirely fair enough if so. As soon as I
know the reason I'm happy to try and fix things to accomodate that reason
and maintain existing behaviour.
Until then, I'm attaching a patch against current CVS to revert it. I
have checkin access to /cvs/src if that helps.
Jifl
2005-06-09 Jonathan Larmour <jifl@eCosCentric.com>
* elflink.c (bfd_elf_gc_sections): Revert change of 2004-04-21 to
not mark dependencies of .eh_frame. There is nowhere else such
marking would happen so they need to be kept.
Index: elflink.c
===================================================================
RCS file: /cvs/src/src/bfd/elflink.c,v
retrieving revision 1.167
diff -u -5 -p -r1.167 elflink.c
--- elflink.c 9 Jun 2005 02:02:17 -0000 1.167
+++ elflink.c 9 Jun 2005 10:25:00 -0000
@@ -9124,16 +9124,11 @@ bfd_elf_gc_sections (bfd *abfd, struct b
for (o = sub->sections; o != NULL; o = o->next)
{
if (o->flags & SEC_KEEP)
{
- /* _bfd_elf_discard_section_eh_frame knows how to discard
- orphaned FDEs so don't mark sections referenced by the
- EH frame section. */
- if (strcmp (o->name, ".eh_frame") == 0)
- o->gc_mark = 1;
- else if (!_bfd_elf_gc_mark (info, o, gc_mark_hook))
+ if (!_bfd_elf_gc_mark (info, o, gc_mark_hook))
return FALSE;
}
}
}
--
eCosCentric http://www.eCosCentric.com/ The eCos and RedBoot experts
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: gc sections and .eh_frame
2005-06-09 10:33 ` Jonathan Larmour
@ 2005-06-09 11:38 ` Eric Botcazou
2005-06-09 12:07 ` Jonathan Larmour
0 siblings, 1 reply; 50+ messages in thread
From: Eric Botcazou @ 2005-06-09 11:38 UTC (permalink / raw)
To: Jonathan Larmour; +Cc: binutils
> So far, no-one has given any rationalisation for the change. It wasn't
> posted to this list, so there's no reason given there.
Huh... didn't you see the link I posted? Here is it again:
http://sourceware.org/ml/binutils/2004-03/msg00424.html
> To my eye, the change doesn't seem right - if a section is a dependency
> of .eh_frame, it needs to be kept. Needing to forcibly KEEP()
> all .gcc_except_table sections should not have been necessary in the first
> place.
Please read the rationale I had given for the change.
--
Eric Botcazou
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: gc sections and .eh_frame
2005-06-09 11:38 ` Eric Botcazou
@ 2005-06-09 12:07 ` Jonathan Larmour
2005-06-09 12:49 ` Alan Modra
2005-06-09 13:02 ` Eric Botcazou
0 siblings, 2 replies; 50+ messages in thread
From: Jonathan Larmour @ 2005-06-09 12:07 UTC (permalink / raw)
To: Eric Botcazou; +Cc: binutils
Eric Botcazou wrote:
>>So far, no-one has given any rationalisation for the change. It wasn't
>>posted to this list, so there's no reason given there.
>
>
> Huh... didn't you see the link I posted? Here is it again:
> http://sourceware.org/ml/binutils/2004-03/msg00424.html
I had missed that in your previous reply, my apologies. I also did not
find it in the archives because it was over a month until the time it was
committed.
>>To my eye, the change doesn't seem right - if a section is a dependency
>>of .eh_frame, it needs to be kept. Needing to forcibly KEEP()
>>all .gcc_except_table sections should not have been necessary in the first
>>place.
>
>
> Please read the rationale I had given for the change.
Thank you. However I still fail to understand (my fault I'm sure) why
dependencies of .eh_frame. should not be marked. Surely if the
.gcc_except_table section has been split up into multiple sections,
courtesy of -ffunction-sections, then that's all the more reason to mark
.eh_frame's dependencies?
Can I ask where the used .gcc_except_table.* sections _are_ meant to be
marked? I cannot see anywhere that _bfd_elf_discard_section_eh_frame does
it, for example. Why would .gcc_except_table.* get marked, but .rodata not
get marked for powerpc?
Separately, I still consider it an issue to break existing linker scripts
(and the failure mode is very obscure and difficult to track down when you
encounter it, I can tell you!). That doesn't bother me personally since
I've fixed mine (other than ppc), but for others it doesn't seem like a
good idea to do casually.
Jifl
--
eCosCentric http://www.eCosCentric.com/ The eCos and RedBoot experts
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: gc sections and .eh_frame
2005-06-09 12:07 ` Jonathan Larmour
@ 2005-06-09 12:49 ` Alan Modra
2005-06-09 13:02 ` Eric Botcazou
1 sibling, 0 replies; 50+ messages in thread
From: Alan Modra @ 2005-06-09 12:49 UTC (permalink / raw)
To: Jonathan Larmour; +Cc: Eric Botcazou, binutils
On Thu, Jun 09, 2005 at 01:07:58PM +0100, Jonathan Larmour wrote:
> Can I ask where the used .gcc_except_table.* sections _are_ meant to be
> marked? I cannot see anywhere that _bfd_elf_discard_section_eh_frame does
> it, for example. Why would .gcc_except_table.* get marked, but .rodata not
> get marked for powerpc?
I think Eric cheated, and put a KEEP in the linker script.
As far as .eh_frame is concerned, the problem is that gcc doesn't emit
eh info to uniquely named sections for each function when compiling with
-ffunction-sections -fdata-sections. Instead, you get it all lumped
into one section. Since ld's --gc-sections option works by looking at
relocs on a section by section basis, if .eh_frame is kept, then all
sections referred to by .eh_frame will be kept. And .eh_frame typically
references function code sections..
Relocation section '.rela.eh_frame' at offset 0x1293c contains 15 entries:
Offset Info Type Sym. Value Symbol's Name + Addend
00000012 0000b901 R_PPC_ADDR32 00000000 __gxx_personality_v0 + 0
00000024 00000801 R_PPC_ADDR32 00000000 .text._ZNSt8ios_base17_M_call_callbacksENS_5eventE + 0
0000002d 00000901 R_PPC_ADDR32 00000000 .rodata + 0
00000048 00000a01 R_PPC_ADDR32 00000000 .text._ZNSt8ios_base20_M_dispose_callbacksEv + 0
00000068 00000b01 R_PPC_ADDR32 00000000 .text._ZNSt8ios_baseD2Ev + 0
00000071 00000901 R_PPC_ADDR32 00000000 .rodata + 1d
00000088 00000c01 R_PPC_ADDR32 00000000 .text._ZNSt8ios_baseD1Ev + 0
00000091 00000901 R_PPC_ADDR32 00000000 .rodata + 2a
000000a8 00000d01 R_PPC_ADDR32 00000000 .text._ZNSt8ios_baseD0Ev + 0
000000b1 00000901 R_PPC_ADDR32 00000000 .rodata + 37
000000c8 00001001 R_PPC_ADDR32 00000000 .text._ZNSt8ios_base6xallocEv + 0
000000d1 00000901 R_PPC_ADDR32 00000000 .rodata + 48
000000e4 00001101 R_PPC_ADDR32 00000000 .text._ZNSt8ios_base17register_callbackEPFvNS_5eventERS_iEi + 0
0000010c 00001501 R_PPC_ADDR32 00000000 .text._ZNSt8ios_base13_M_grow_wordsEib + 0
00000115 00000901 R_PPC_ADDR32 00000000 .rodata + 5c
--
Alan Modra
IBM OzLabs - Linux Technology Centre
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: gc sections and .eh_frame
2005-06-09 12:07 ` Jonathan Larmour
2005-06-09 12:49 ` Alan Modra
@ 2005-06-09 13:02 ` Eric Botcazou
2005-06-09 13:50 ` Jonathan Larmour
1 sibling, 1 reply; 50+ messages in thread
From: Eric Botcazou @ 2005-06-09 13:02 UTC (permalink / raw)
To: Jonathan Larmour; +Cc: binutils
> Can I ask where the used .gcc_except_table.* sections _are_ meant to be
> marked? I cannot see anywhere that _bfd_elf_discard_section_eh_frame does
> it, for example.
The (patched) compiler will mark them.
> Why would .gcc_except_table.* get marked, but .rodata not get marked for
> powerpc?
Clearly .rodata needs to be explicitly KEEPed for your powerpc target, the
same way .gcc_except_table has been marked as KEEP for generic ELF.
> Separately, I still consider it an issue to break existing linker scripts
> (and the failure mode is very obscure and difficult to track down when you
> encounter it, I can tell you!).
The alternative is a useless -function-sections --gc-sections with DWARF-2 EH.
--
Eric Botcazou
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: gc sections and .eh_frame
2005-06-09 13:02 ` Eric Botcazou
@ 2005-06-09 13:50 ` Jonathan Larmour
2005-06-09 14:22 ` Eric Botcazou
0 siblings, 1 reply; 50+ messages in thread
From: Jonathan Larmour @ 2005-06-09 13:50 UTC (permalink / raw)
To: Eric Botcazou; +Cc: binutils
Eric Botcazou wrote:
>>Can I ask where the used .gcc_except_table.* sections _are_ meant to be
>>marked? I cannot see anywhere that _bfd_elf_discard_section_eh_frame does
>>it, for example.
>
>
> The (patched) compiler will mark them.
I can't see the changes in GCC CVS, so I guess they are not even in the
4.0.0 release. So it will be a long time before powerpc-eabi can start
working again courtesy of that.
>>Why would .gcc_except_table.* get marked, but .rodata not get marked for
>>powerpc?
>
>
> Clearly .rodata needs to be explicitly KEEPed for your powerpc target, the
> same way .gcc_except_table has been marked as KEEP for generic ELF.
That's quite a sledgehammer approach! The overhead of garbage collectable
stuff in .rodata is substantially more than .gcc_except_table. For my own
use, right now, I've just reverted the patch.
But how do we fix this in binutils for other powerpc-eabi users?
Is it possible that instead of just immediately going ahead with not
marking .eh_frame dependencies, we only do that if there _is_ a section
named .gcc_except_table in the object? That would both catch the case of
powerpc-eabi and any others we don't yet know about (there's no reason to
think powerpc-eabi is definitely the only one).
In other words, something like the following?
for (o = sub->sections; o != NULL; o = o->next)
{
if (o->flags & SEC_KEEP)
{
/* _bfd_elf_discard_section_eh_frame knows how to discard
orphaned FDEs so don't mark sections referenced by the
EH frame section. */
if ((strcmp (o->name, ".eh_frame") == 0) &&
(bfd_get_section_by_name (abfd, ".gcc_except_table") !=
NULL))
o->gc_mark = 1;
else if (!_bfd_elf_gc_mark (info, o, gc_mark_hook))
return FALSE;
}
}
}
If you think this looks right and you agree with the principle, I can try
it out.
>>Separately, I still consider it an issue to break existing linker scripts
>>(and the failure mode is very obscure and difficult to track down when you
>>encounter it, I can tell you!).
>
>
> The alternative is a useless -function-sections --gc-sections with DWARF-2 EH.
Not quite useless, just more limited. And if it's a choice between not
working and limited, I'd choose the latter! :-)
Seriously, if it's a conscious decision to break existing linker scripts
in this case, that's fine. I just want to make sure people are aware that
that's the effect.
Jifl
--
eCosCentric http://www.eCosCentric.com/ The eCos and RedBoot experts
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: gc sections and .eh_frame
2005-06-09 13:50 ` Jonathan Larmour
@ 2005-06-09 14:22 ` Eric Botcazou
2005-06-09 14:33 ` Jonathan Larmour
0 siblings, 1 reply; 50+ messages in thread
From: Eric Botcazou @ 2005-06-09 14:22 UTC (permalink / raw)
To: Jonathan Larmour; +Cc: binutils
> That's quite a sledgehammer approach! The overhead of garbage collectable
> stuff in .rodata is substantially more than .gcc_except_table. For my own
> use, right now, I've just reverted the patch.
Since -function-sections --gc-sections doesn't work in presence of DWARF-2 EH,
you could simply not pass -function-sections to the compiler.
> Is it possible that instead of just immediately going ahead with not
> marking .eh_frame dependencies, we only do that if there _is_ a section
> named .gcc_except_table in the object? That would both catch the case of
> powerpc-eabi and any others we don't yet know about (there's no reason to
> think powerpc-eabi is definitely the only one).
>
> In other words, something like the following?
>
> for (o = sub->sections; o != NULL; o = o->next)
> {
> if (o->flags & SEC_KEEP)
> {
> /* _bfd_elf_discard_section_eh_frame knows how to discard
> orphaned FDEs so don't mark sections referenced by the
> EH frame section. */
> if ((strcmp (o->name, ".eh_frame") == 0) &&
> (bfd_get_section_by_name (abfd, ".gcc_except_table") !=
> NULL))
> o->gc_mark = 1;
> else if (!_bfd_elf_gc_mark (info, o, gc_mark_hook))
> return FALSE;
> }
> }
> }
>
> If you think this looks right and you agree with the principle, I can try
> it out.
I'm not sure the .gcc_except_table section has already been created by the
time bfd_elf_gc_sections is invoked. I'm looking into it.
--
Eric Botcazou
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: gc sections and .eh_frame
2005-06-09 14:22 ` Eric Botcazou
@ 2005-06-09 14:33 ` Jonathan Larmour
2005-06-10 4:23 ` Alan Modra
2005-06-10 11:55 ` Eric Botcazou
0 siblings, 2 replies; 50+ messages in thread
From: Jonathan Larmour @ 2005-06-09 14:33 UTC (permalink / raw)
To: Eric Botcazou; +Cc: binutils
Eric Botcazou wrote:
>>That's quite a sledgehammer approach! The overhead of garbage collectable
>>stuff in .rodata is substantially more than .gcc_except_table. For my own
>>use, right now, I've just reverted the patch.
>
>
> Since -function-sections --gc-sections doesn't work in presence of DWARF-2 EH,
> you could simply not pass -function-sections to the compiler.
Ah, the issue being on embedded targets (as powerpc-eabi is implicitly),
people are normally selective about what they allow to be compiled without
-fno-exceptions. In the case of eCos, the OS is fully linked to the
application, and almost none of the OS wants to use C++ exceptions. This
translates to large savings with gc sections.
I expect anyone else using eCos or their own embedded OS would be
similarly selective.
> I'm not sure the .gcc_except_table section has already been created by the
> time bfd_elf_gc_sections is invoked. I'm looking into it.
Great, thanks. I guess looping over the input BFDs would be better.
Jifl
--
eCosCentric http://www.eCosCentric.com/ The eCos and RedBoot experts
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: gc sections and .eh_frame
2005-06-09 14:33 ` Jonathan Larmour
@ 2005-06-10 4:23 ` Alan Modra
2005-06-10 6:46 ` Eric Botcazou
2005-06-10 11:55 ` Eric Botcazou
1 sibling, 1 reply; 50+ messages in thread
From: Alan Modra @ 2005-06-10 4:23 UTC (permalink / raw)
To: Jonathan Larmour; +Cc: Eric Botcazou, binutils, gcc-patches, David Edelsohn
On Thu, Jun 09, 2005 at 03:34:20PM +0100, Jonathan Larmour wrote:
> Eric Botcazou wrote:
> >>That's quite a sledgehammer approach! The overhead of garbage collectable
> >>stuff in .rodata is substantially more than .gcc_except_table. For my own
> >>use, right now, I've just reverted the patch.
> >
> >Since -function-sections --gc-sections doesn't work in presence of DWARF-2
> >EH, you could simply not pass -function-sections to the compiler.
>
> Ah, the issue being on embedded targets (as powerpc-eabi is implicitly),
> people are normally selective about what they allow to be compiled without
> -fno-exceptions. In the case of eCos, the OS is fully linked to the
> application, and almost none of the OS wants to use C++ exceptions. This
> translates to large savings with gc sections.
Actually, it's not just eabi that is affected by this problem, but all
sysv4 abi powerpc targets, which includes powerpc-linux. I've done some
digging through gcc CVS to see why this problem occurred, and found:
Geoff introduced #define EXCEPTION_SECTION readonly_data_section
here: http://gcc.gnu.org/ml/gcc-patches/2001-05/msg00812.html
All well and good, it was an improvement over using data_section
Over time though, we eventually had a default_exception_section that
could generate a read-only .gcc_except_table, so there is now no need
for the define in rs6000/sysv4.h, and of course using .rodata can result
in ld --gc-sections deleting needed exception information. I'll be
committing a gcc patch soon to fix this on all active gcc branches,
pre-approved by David Edelsohn.
* config/rs6000/sysv4.h (TARGET_ASM_EXCEPTION_SECTION): Delete.
Index: gcc/config/rs6000/sysv4.h
===================================================================
RCS file: /cvs/gcc/gcc/gcc/config/rs6000/sysv4.h,v
retrieving revision 1.163
diff -u -p -r1.163 sysv4.h
--- gcc/config/rs6000/sysv4.h 1 Jun 2005 00:30:22 -0000 1.163
+++ gcc/config/rs6000/sysv4.h 10 Jun 2005 04:19:39 -0000
@@ -1284,8 +1284,6 @@ ncrtn.o%s"
? (((GLOBAL) ? DW_EH_PE_indirect : 0) | DW_EH_PE_pcrel | DW_EH_PE_sdata4) \
: DW_EH_PE_absptr)
-#define TARGET_ASM_EXCEPTION_SECTION readonly_data_section
-
#define DOUBLE_INT_ASM_OP "\t.quad\t"
/* Generate entries in .fixup for relocatable addresses. */
--
Alan Modra
IBM OzLabs - Linux Technology Centre
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: gc sections and .eh_frame
2005-06-10 4:23 ` Alan Modra
@ 2005-06-10 6:46 ` Eric Botcazou
2005-06-10 11:49 ` Jonathan Larmour
0 siblings, 1 reply; 50+ messages in thread
From: Eric Botcazou @ 2005-06-10 6:46 UTC (permalink / raw)
To: Alan Modra; +Cc: gcc-patches, Jonathan Larmour, binutils, David Edelsohn
> I'll be committing a gcc patch soon to fix this on all active gcc branches,
> pre-approved by David Edelsohn.
>
> * config/rs6000/sysv4.h (TARGET_ASM_EXCEPTION_SECTION): Delete.
Thanks for tracking this down!
--
Eric Botcazou
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: gc sections and .eh_frame
2005-06-10 6:46 ` Eric Botcazou
@ 2005-06-10 11:49 ` Jonathan Larmour
0 siblings, 0 replies; 50+ messages in thread
From: Jonathan Larmour @ 2005-06-10 11:49 UTC (permalink / raw)
To: Eric Botcazou; +Cc: Alan Modra, binutils
Eric Botcazou wrote:
>>I'll be committing a gcc patch soon to fix this on all active gcc branches,
>>pre-approved by David Edelsohn.
>>
>> * config/rs6000/sysv4.h (TARGET_ASM_EXCEPTION_SECTION): Delete.
>
>
> Thanks for tracking this down!
Agreed, thanks! And hopefully that does mean it won't affect other
architectures after all.
But that still leaves us with a huge time gap between now, and when GCC
CVS after the patch finally reaches gcc 4.1.0.
So I would still be keen on pursuing a workaround in binutils, perhaps
along the lines of what I suggested (seeing if .gcc_except_table is in the
input sections), or anything else anyone thinks would work. Adding a
special case for powerpc probably wouldn't be wise as it wouldn't be
appropriate for gcc 4.1.
Jifl
--
eCosCentric http://www.eCosCentric.com/ The eCos and RedBoot experts
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: gc sections and .eh_frame
2005-06-09 14:33 ` Jonathan Larmour
2005-06-10 4:23 ` Alan Modra
@ 2005-06-10 11:55 ` Eric Botcazou
2005-06-10 12:09 ` Alan Modra
1 sibling, 1 reply; 50+ messages in thread
From: Eric Botcazou @ 2005-06-10 11:55 UTC (permalink / raw)
To: Jonathan Larmour; +Cc: binutils
[-- Attachment #1: Type: text/plain, Size: 309 bytes --]
> Great, thanks. I guess looping over the input BFDs would be better.
Right, I think it's the best approach. Not very pretty but it works for me.
* elflink.c (bfd_elf_gc_sections): Mark again the sections rooted
at .eh_frame if the EH tables are not in .gcc_except_table.* sections.
--
Eric Botcazou
[-- Attachment #2: d106-019_linker-2.diff --]
[-- Type: text/x-diff, Size: 1785 bytes --]
Index: elflink.c
===================================================================
RCS file: /cvs/src/src/bfd/elflink.c,v
retrieving revision 1.136.2.3
diff -u -p -r1.136.2.3 elflink.c
--- elflink.c 27 Apr 2005 16:47:24 -0000 1.136.2.3
+++ elflink.c 10 Jun 2005 11:43:48 -0000
@@ -9031,6 +9031,8 @@ bfd_elf_gc_sections (bfd *abfd, struct b
asection * (*gc_mark_hook)
(asection *, struct bfd_link_info *, Elf_Internal_Rela *,
struct elf_link_hash_entry *h, Elf_Internal_Sym *);
+ bfd_boolean has_gcc_except_table = FALSE;
+ asection *eh_frame = NULL;
if (!get_elf_backend_data (abfd)->can_gc_sections
|| info->relocatable
@@ -9081,13 +9083,31 @@ bfd_elf_gc_sections (bfd *abfd, struct b
orphaned FDEs so don't mark sections referenced by the
EH frame section. */
if (strcmp (o->name, ".eh_frame") == 0)
- o->gc_mark = 1;
+ {
+ o->gc_mark = 1;
+ eh_frame = o;
+ }
else if (!_bfd_elf_gc_mark (info, o, gc_mark_hook))
return FALSE;
}
+
+ /* Detect .gcc_except_table.* sections in the input files. */
+ if (!has_gcc_except_table
+ && strncmp (o->name, ".gcc_except_table", 17) == 0)
+ has_gcc_except_table = TRUE;
}
}
+ /* If we have not detected .gcc_except_table.* sections in the input files,
+ that probably means the target uses a specific section for the EH tables.
+ Play safe and let .eh_frame mark the sections it really needs, since we
+ will not be able to do it explicitly. */
+ if (eh_frame && !has_gcc_except_table)
+ {
+ if (!_bfd_elf_gc_mark (info, eh_frame, gc_mark_hook))
+ return FALSE;
+ }
+
/* ... and mark SEC_EXCLUDE for those that go. */
if (!elf_gc_sweep (info, get_elf_backend_data (abfd)->gc_sweep_hook))
return FALSE;
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: gc sections and .eh_frame
2005-06-10 11:55 ` Eric Botcazou
@ 2005-06-10 12:09 ` Alan Modra
2005-06-10 12:51 ` Jonathan Larmour
2005-06-10 13:35 ` Eric Botcazou
0 siblings, 2 replies; 50+ messages in thread
From: Alan Modra @ 2005-06-10 12:09 UTC (permalink / raw)
To: Eric Botcazou; +Cc: Jonathan Larmour, binutils
On Fri, Jun 10, 2005 at 01:54:36PM +0200, Eric Botcazou wrote:
> > Great, thanks. I guess looping over the input BFDs would be better.
>
> Right, I think it's the best approach. Not very pretty but it works for me.
>
>
> * elflink.c (bfd_elf_gc_sections): Mark again the sections rooted
> at .eh_frame if the EH tables are not in .gcc_except_table.* sections.
Won't that mark all the function text sections too?
--
Alan Modra
IBM OzLabs - Linux Technology Centre
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: gc sections and .eh_frame
2005-06-10 12:09 ` Alan Modra
@ 2005-06-10 12:51 ` Jonathan Larmour
2005-06-10 13:44 ` Eric Botcazou
2005-06-10 13:35 ` Eric Botcazou
1 sibling, 1 reply; 50+ messages in thread
From: Jonathan Larmour @ 2005-06-10 12:51 UTC (permalink / raw)
To: Alan Modra; +Cc: Eric Botcazou, binutils
Alan Modra wrote:
> On Fri, Jun 10, 2005 at 01:54:36PM +0200, Eric Botcazou wrote:
>
>>>Great, thanks. I guess looping over the input BFDs would be better.
>>
>>Right, I think it's the best approach. Not very pretty but it works for me.
>>
>>
>> * elflink.c (bfd_elf_gc_sections): Mark again the sections rooted
>> at .eh_frame if the EH tables are not in .gcc_except_table.* sections.
>
>
> Won't that mark all the function text sections too?
Only if there aren't any .gcc_except_table* sections surely? In which case
that's no worse than previous behaviour.
Anyway, unfortunately the patch doesn't quite work. There are multiple
input .eh_frame sections, and only the most recently seen one will get its
dependencies marked.
While it would be good to reuse the loop, I think we're going to have to
do a separate loop to search for .gcc_except_table*. I'll rework the patch.
Jifl
--
eCosCentric http://www.eCosCentric.com/ The eCos and RedBoot experts
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: gc sections and .eh_frame
2005-06-10 12:09 ` Alan Modra
2005-06-10 12:51 ` Jonathan Larmour
@ 2005-06-10 13:35 ` Eric Botcazou
1 sibling, 0 replies; 50+ messages in thread
From: Eric Botcazou @ 2005-06-10 13:35 UTC (permalink / raw)
To: Alan Modra; +Cc: Jonathan Larmour, binutils
> > * elflink.c (bfd_elf_gc_sections): Mark again the sections rooted
> > at .eh_frame if the EH tables are not in .gcc_except_table.* sections.
>
> Won't that mark all the function text sections too?
Aren't they automatically marked if the EH tables are?
--
Eric Botcazou
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: gc sections and .eh_frame
2005-06-10 12:51 ` Jonathan Larmour
@ 2005-06-10 13:44 ` Eric Botcazou
2005-06-10 14:26 ` Jonathan Larmour
0 siblings, 1 reply; 50+ messages in thread
From: Eric Botcazou @ 2005-06-10 13:44 UTC (permalink / raw)
To: Jonathan Larmour; +Cc: Alan Modra, binutils
[-- Attachment #1: Type: text/plain, Size: 484 bytes --]
> Anyway, unfortunately the patch doesn't quite work. There are multiple
> input .eh_frame sections, and only the most recently seen one will get its
> dependencies marked.
Oops. Totally broken would be the right wording. :-)
> While it would be good to reuse the loop, I think we're going to have to
> do a separate loop to search for .gcc_except_table*.
Could we not simply move the invocation of _bfd_elf_gc_mark inside the loop?
A new revision is attached.
--
Eric Botcazou
[-- Attachment #2: d106-019_linker-2b.diff --]
[-- Type: text/x-diff, Size: 1691 bytes --]
Index: elflink.c
===================================================================
RCS file: /cvs/src/src/bfd/elflink.c,v
retrieving revision 1.136.2.3
diff -u -p -r1.136.2.3 elflink.c
--- elflink.c 27 Apr 2005 16:47:24 -0000 1.136.2.3
+++ elflink.c 10 Jun 2005 13:42:38 -0000
@@ -9068,6 +9068,8 @@ bfd_elf_gc_sections (bfd *abfd, struct b
gc_mark_hook = get_elf_backend_data (abfd)->gc_mark_hook;
for (sub = info->input_bfds; sub != NULL; sub = sub->link_next)
{
+ bfd_boolean has_gcc_except_table = FALSE;
+ asection *eh_frame = NULL;
asection *o;
if (bfd_get_flavour (sub) != bfd_target_elf_flavour)
@@ -9081,11 +9083,29 @@ bfd_elf_gc_sections (bfd *abfd, struct b
orphaned FDEs so don't mark sections referenced by the
EH frame section. */
if (strcmp (o->name, ".eh_frame") == 0)
- o->gc_mark = 1;
+ {
+ o->gc_mark = 1;
+ eh_frame = o;
+ }
else if (!_bfd_elf_gc_mark (info, o, gc_mark_hook))
return FALSE;
}
+
+ /* Detect .gcc_except_table.* sections in the input file. */
+ if (!has_gcc_except_table
+ && strncmp (o->name, ".gcc_except_table", 17) == 0)
+ has_gcc_except_table = TRUE;
}
+
+ /* If we have not detected .gcc_except_table.* sections in the input
+ file, that probably means the target uses a specific section for
+ the EH tables. Play safe and let .eh_frame mark the sections it
+ really needs, since we will not be able to do it explicitly. */
+ if (eh_frame && !has_gcc_except_table)
+ {
+ if (!_bfd_elf_gc_mark (info, eh_frame, gc_mark_hook))
+ return FALSE;
+ }
}
/* ... and mark SEC_EXCLUDE for those that go. */
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: gc sections and .eh_frame
2005-06-10 13:44 ` Eric Botcazou
@ 2005-06-10 14:26 ` Jonathan Larmour
2005-06-10 14:50 ` Eric Botcazou
0 siblings, 1 reply; 50+ messages in thread
From: Jonathan Larmour @ 2005-06-10 14:26 UTC (permalink / raw)
To: Eric Botcazou; +Cc: Alan Modra, binutils
Eric Botcazou wrote:
> Could we not simply move the invocation of _bfd_elf_gc_mark inside the loop?
> A new revision is attached.
Indeed so, well thought! I've tested it with powerpc-eabi and it works
fine. I'm happy with that, great work, thanks!
Jifl
--
eCosCentric http://www.eCosCentric.com/ The eCos and RedBoot experts
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: gc sections and .eh_frame
2005-06-10 14:26 ` Jonathan Larmour
@ 2005-06-10 14:50 ` Eric Botcazou
2005-06-10 14:58 ` Jonathan Larmour
2005-06-22 11:46 ` Jonathan Larmour
0 siblings, 2 replies; 50+ messages in thread
From: Eric Botcazou @ 2005-06-10 14:50 UTC (permalink / raw)
To: Jonathan Larmour; +Cc: binutils, Alan Modra
> Indeed so, well thought! I've tested it with powerpc-eabi and it works
> fine. I'm happy with that, great work, thanks!
Thanks for confirming. However I think I've grasped Alan's remark and we
indeed risk marking all the functions in a given input file if it happens to
contain no EH tables because its functions don't need them.
I can think of 2 solutions: a second loop as you initially suggested or to add
a new parameter 'skip_code' to _bfd_elf_gc_mark to skip SEC_CODE sections
when it is invoked on .eh_frame. Alan will decide whether the latter approach
is easily implementable.
--
Eric Botcazou
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: gc sections and .eh_frame
2005-06-10 14:50 ` Eric Botcazou
@ 2005-06-10 14:58 ` Jonathan Larmour
2005-06-10 15:13 ` Eric Botcazou
2005-06-22 11:46 ` Jonathan Larmour
1 sibling, 1 reply; 50+ messages in thread
From: Jonathan Larmour @ 2005-06-10 14:58 UTC (permalink / raw)
To: Eric Botcazou; +Cc: binutils, Alan Modra
Eric Botcazou wrote:
>>Indeed so, well thought! I've tested it with powerpc-eabi and it works
>>fine. I'm happy with that, great work, thanks!
>
>
> Thanks for confirming. However I think I've grasped Alan's remark and we
> indeed risk marking all the functions in a given input file if it happens to
> contain no EH tables because its functions don't need them.
Can that really happen in practice? Doesn't that mean having a .eh_frame
input section present and (on non-powerpc targets) no .gcc_except_frame?
> I can think of 2 solutions: a second loop as you initially suggested or to add
> a new parameter 'skip_code' to _bfd_elf_gc_mark to skip SEC_CODE sections
> when it is invoked on .eh_frame. Alan will decide whether the latter approach
> is easily implementable.
Since I'm not sure I understand the issue, I'll certainly leave it to you
two to decide.
Jifl
--
eCosCentric http://www.eCosCentric.com/ The eCos and RedBoot experts
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: gc sections and .eh_frame
2005-06-10 14:58 ` Jonathan Larmour
@ 2005-06-10 15:13 ` Eric Botcazou
0 siblings, 0 replies; 50+ messages in thread
From: Eric Botcazou @ 2005-06-10 15:13 UTC (permalink / raw)
To: Jonathan Larmour; +Cc: binutils, Alan Modra
> > Thanks for confirming. However I think I've grasped Alan's remark and we
> > indeed risk marking all the functions in a given input file if it happens
> > to contain no EH tables because its functions don't need them.
>
> Can that really happen in practice? Doesn't that mean having a .eh_frame
> input section present and (on non-powerpc targets) no .gcc_except_frame?
Yes, that can happen if no functions in the file use EH constructs, which is
not uncommon I think. For example in Ada:
with U;
procedure Ma is
i : Integer := 10;
begin
U.Used (i);
end Ma;
.file "ma.adb"
.section .rodata
.LC0:
.string "ma.adb"
.zero 1
.section .text._ada_ma,"ax",@progbits
.globl _ada_ma
.type _ada_ma, @function
_ada_ma:
.LFB2:
pushl %ebp
.LCFI0:
movl %esp, %ebp
.LCFI1:
subl $8, %esp
.LCFI2:
movl $10, -4(%ebp)
subl $12, %esp
cmpl $0, -4(%ebp)
js .L4
cmpl $10, -4(%ebp)
jg .L4
jmp .L2
.L4:
subl $12, %esp
pushl $5
pushl $.LC0
.LCFI3:
call __gnat_rcheck_11
.L2:
movl -4(%ebp), %eax
pushl %eax
.LCFI4:
call u__used
addl $16, %esp
movl %eax, -4(%ebp)
leave
ret
.LFE2:
.size _ada_ma, .-_ada_ma
.section .eh_frame,"a",@progbits
.Lframe1:
.long .LECIE1-.LSCIE1
.LSCIE1:
.long 0x0
.byte 0x1
.string "zP"
.uleb128 0x1
.sleb128 -4
.byte 0x8
.uleb128 0x5
.byte 0x0
.long __gnat_eh_personality
.byte 0xc
.uleb128 0x4
.uleb128 0x4
.byte 0x88
.uleb128 0x1
.align 4
.LECIE1:
.LSFDE1:
.long .LEFDE1-.LASFDE1
.LASFDE1:
.long .LASFDE1-.Lframe1
.long .LFB2
.long .LFE2-.LFB2
.uleb128 0x0
.byte 0x4
.long .LCFI0-.LFB2
.byte 0xe
.uleb128 0x8
.byte 0x85
.uleb128 0x2
.byte 0x4
.long .LCFI1-.LCFI0
.byte 0xd
.uleb128 0x5
.byte 0x4
.long .LCFI3-.LCFI1
.byte 0x2e
.uleb128 0x14
.byte 0x4
.long .LCFI4-.LCFI3
.byte 0x2e
.uleb128 0x10
.align 4
.LEFDE1:
.section .note.GNU-stack,"",@progbits
.ident "GCC: (GNU) 3.4.5 20050607 (prerelease)"
--
Eric Botcazou
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: gc sections and .eh_frame
2005-06-10 14:50 ` Eric Botcazou
2005-06-10 14:58 ` Jonathan Larmour
@ 2005-06-22 11:46 ` Jonathan Larmour
2005-06-25 17:28 ` Alan Modra
1 sibling, 1 reply; 50+ messages in thread
From: Jonathan Larmour @ 2005-06-22 11:46 UTC (permalink / raw)
To: Eric Botcazou; +Cc: binutils, Alan Modra
Eric Botcazou wrote:
>>Indeed so, well thought! I've tested it with powerpc-eabi and it works
>>fine. I'm happy with that, great work, thanks!
>
>
> Thanks for confirming. However I think I've grasped Alan's remark and we
> indeed risk marking all the functions in a given input file if it happens to
> contain no EH tables because its functions don't need them.
>
> I can think of 2 solutions: a second loop as you initially suggested or to add
> a new parameter 'skip_code' to _bfd_elf_gc_mark to skip SEC_CODE sections
> when it is invoked on .eh_frame. Alan will decide whether the latter approach
> is easily implementable.
I think Alan maybe didn't notice his name being mentioned :). Alan, do you
have any guidance on the best approach?
Jifl
--
eCosCentric http://www.eCosCentric.com/ The eCos and RedBoot experts
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: gc sections and .eh_frame
2005-06-22 11:46 ` Jonathan Larmour
@ 2005-06-25 17:28 ` Alan Modra
2005-06-27 11:56 ` Eric Botcazou
0 siblings, 1 reply; 50+ messages in thread
From: Alan Modra @ 2005-06-25 17:28 UTC (permalink / raw)
To: Jonathan Larmour; +Cc: Eric Botcazou, binutils
On Wed, Jun 22, 2005 at 12:46:21PM +0100, Jonathan Larmour wrote:
> I think Alan maybe didn't notice his name being mentioned :). Alan, do you
> have any guidance on the best approach?
None of the proposed solutions is right. If you take a look at a
typical .eh_frame, you'll see relocs pointing at text sections and
.gcc_except_table (or .rodata for broken ppc compilers). Changing
garbage collection to process .rela.eh_frame thus runs into the problem
of distinguishing the two types of reloc: You need to ignore the
former, and mark sections for the latter.
Try the following totally untested patch.
* elflink.c (_bfd_elf_gc_mark): Handle .eh_frame relocs specially..
(bfd_elf_gc_sections): ..rather than totally ignoring .eh_frame.
Don't recheck sections we have already marked.
--- bfd/elflink.c~ 2005-06-16 12:18:15.000000000 +0930
+++ bfd/elflink.c 2005-06-26 02:17:09.464213143 +0930
@@ -8733,6 +8733,7 @@
gc_mark_hook_fn gc_mark_hook)
{
bfd_boolean ret;
+ bfd_boolean is_eh;
asection *group_sec;
sec->gc_mark = 1;
@@ -8745,6 +8746,7 @@
/* Look through the section relocs. */
ret = TRUE;
+ is_eh = strcmp (sec->name, ".eh_frame") == 0;
if ((sec->flags & SEC_RELOC) != 0 && sec->reloc_count > 0)
{
Elf_Internal_Rela *relstart, *rel, *relend;
@@ -8817,7 +8819,10 @@
rsec = (*gc_mark_hook) (sec, info, rel, NULL, &isym[r_symndx]);
}
- if (rsec && !rsec->gc_mark)
+ if (rsec && !rsec->gc_mark
+ /* Don't mark code sections referenced by .eh_frame,
+ otherwise we'll mark all code sections in this file. */
+ && !(is_eh && (rsec->flags & SEC_CODE) != 0))
{
if (bfd_get_flavour (rsec->owner) != bfd_target_elf_flavour)
rsec->gc_mark = 1;
@@ -9123,18 +9128,9 @@
continue;
for (o = sub->sections; o != NULL; o = o->next)
- {
- if (o->flags & SEC_KEEP)
- {
- /* _bfd_elf_discard_section_eh_frame knows how to discard
- orphaned FDEs so don't mark sections referenced by the
- EH frame section. */
- if (strcmp (o->name, ".eh_frame") == 0)
- o->gc_mark = 1;
- else if (!_bfd_elf_gc_mark (info, o, gc_mark_hook))
- return FALSE;
- }
- }
+ if ((o->flags & SEC_KEEP) != 0 && !o->gc_mark)
+ if (!_bfd_elf_gc_mark (info, o, gc_mark_hook))
+ return FALSE;
}
/* ... and mark SEC_EXCLUDE for those that go. */
--
Alan Modra
IBM OzLabs - Linux Technology Centre
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: gc sections and .eh_frame
2005-06-25 17:28 ` Alan Modra
@ 2005-06-27 11:56 ` Eric Botcazou
2005-06-28 2:58 ` Alan Modra
0 siblings, 1 reply; 50+ messages in thread
From: Eric Botcazou @ 2005-06-27 11:56 UTC (permalink / raw)
To: Alan Modra; +Cc: binutils, Jonathan Larmour
[-- Attachment #1: Type: text/plain, Size: 1536 bytes --]
> None of the proposed solutions is right. If you take a look at a
> typical .eh_frame, you'll see relocs pointing at text sections and
> .gcc_except_table (or .rodata for broken ppc compilers). Changing
> garbage collection to process .rela.eh_frame thus runs into the problem
> of distinguishing the two types of reloc: You need to ignore the
> former, and mark sections for the latter.
That's exactly what I proposed in my last message, but I suggested passing a
parameter to _bfd_elf_gc_mark to make it "forget" code sections. It seems
autodetecting .eh_frame is more straightforward.
> Try the following totally untested patch.
>
> * elflink.c (_bfd_elf_gc_mark): Handle .eh_frame relocs specially..
> (bfd_elf_gc_sections): ..rather than totally ignoring .eh_frame.
> Don't recheck sections we have already marked.
I think it doesn't work (alone) either, because you unconditionally mark
all .gcc_except_table* sections, which themselves point to the functions.
In normal mode (i.e. with a non broken ppc compiler), we really need avoid
marking any sections referenced by .eh_frame, them being code or data. So I
think that, before invoking _bfd_elf_gc_mark on .eh_frame, we need to make
sure that it doesn't reference .gcc_except_table* sections. Hence the
attached patch.
* elflink.c (_bfd_elf_gc_mark): Don't mark code sections referenced
by .eh_frame.
(bfd_elf_gc_sections): Mark again the sections referenced by .eh_frame
if the EH tables are not in .gcc_except_table* sections.
--
Eric Botcazou
[-- Attachment #2: d106-019_linker-3.diff --]
[-- Type: text/x-diff, Size: 3311 bytes --]
Index: elflink.c
===================================================================
RCS file: /cvs/src/src/bfd/elflink.c,v
retrieving revision 1.136.2.3
diff -u -p -r1.136.2.3 elflink.c
--- elflink.c 27 Apr 2005 16:47:24 -0000 1.136.2.3
+++ elflink.c 27 Jun 2005 11:47:06 -0000
@@ -8687,6 +8687,7 @@ _bfd_elf_gc_mark (struct bfd_link_info *
gc_mark_hook_fn gc_mark_hook)
{
bfd_boolean ret;
+ bfd_boolean is_eh;
asection *group_sec;
sec->gc_mark = 1;
@@ -8699,6 +8700,7 @@ _bfd_elf_gc_mark (struct bfd_link_info *
/* Look through the section relocs. */
ret = TRUE;
+ is_eh = strcmp (sec->name, ".eh_frame") == 0;
if ((sec->flags & SEC_RELOC) != 0 && sec->reloc_count > 0)
{
Elf_Internal_Rela *relstart, *rel, *relend;
@@ -8771,7 +8773,11 @@ _bfd_elf_gc_mark (struct bfd_link_info *
rsec = (*gc_mark_hook) (sec, info, rel, NULL, &isym[r_symndx]);
}
- if (rsec && !rsec->gc_mark)
+ if (rsec
+ && !rsec->gc_mark
+ /* elf-eh-frame.c knows how to discard orphaned FDEs so don't
+ mark code sections referenced by the .eh_frame section. */
+ && !(is_eh && (rsec->flags & SEC_CODE) != 0))
{
if (bfd_get_flavour (rsec->owner) != bfd_target_elf_flavour)
rsec->gc_mark = 1;
@@ -9068,6 +9074,8 @@ bfd_elf_gc_sections (bfd *abfd, struct b
gc_mark_hook = get_elf_backend_data (abfd)->gc_mark_hook;
for (sub = info->input_bfds; sub != NULL; sub = sub->link_next)
{
+ bfd_boolean has_gcc_except_table = FALSE;
+ asection *eh_frame = NULL;
asection *o;
if (bfd_get_flavour (sub) != bfd_target_elf_flavour)
@@ -9077,15 +9085,41 @@ bfd_elf_gc_sections (bfd *abfd, struct b
{
if (o->flags & SEC_KEEP)
{
- /* _bfd_elf_discard_section_eh_frame knows how to discard
- orphaned FDEs so don't mark sections referenced by the
- EH frame section. */
+ /* Marking all sections referenced by .eh_frame effectively
+ disables GC because FDEs contain relocs against both the
+ functions' code and exception table. So we mark none,
+ relying on elf-eh-frame.c to deal with the former type of
+ relocs (it will discard orphaned FDEs) and on the linker
+ script to deal with the latter type if necessary. */
if (strcmp (o->name, ".eh_frame") == 0)
- o->gc_mark = 1;
+ {
+ o->gc_mark = 1;
+ eh_frame = o;
+ }
else if (!_bfd_elf_gc_mark (info, o, gc_mark_hook))
return FALSE;
}
- }
+
+#define GCC_EXCEPT_TABLE_PREFIX ".gcc_except_table"
+
+ /* Detect .gcc_except_table* sections in the input file. */
+ if (!has_gcc_except_table
+ && strncmp (o->name,
+ GCC_EXCEPT_TABLE_PREFIX,
+ strlen (GCC_EXCEPT_TABLE_PREFIX)) == 0)
+ has_gcc_except_table = TRUE;
+ }
+
+ /* If we have not detected .gcc_except_table* sections in the input
+ file, that can mean the target uses a specific section for the
+ EH tables. Play safe and let .eh_frame mark the non-code
+ sections it really needs, since we will presumably not be able
+ to do so explicitly via the linker script if necessary. */
+ if (eh_frame && !has_gcc_except_table)
+ {
+ if (!_bfd_elf_gc_mark (info, eh_frame, gc_mark_hook))
+ return FALSE;
+ }
}
/* ... and mark SEC_EXCLUDE for those that go. */
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: gc sections and .eh_frame
2005-06-27 11:56 ` Eric Botcazou
@ 2005-06-28 2:58 ` Alan Modra
2005-06-28 7:40 ` Eric Botcazou
0 siblings, 1 reply; 50+ messages in thread
From: Alan Modra @ 2005-06-28 2:58 UTC (permalink / raw)
To: Eric Botcazou; +Cc: binutils, Jonathan Larmour
On Mon, Jun 27, 2005 at 01:55:49PM +0200, Eric Botcazou wrote:
> > None of the proposed solutions is right. If you take a look at a
> > typical .eh_frame, you'll see relocs pointing at text sections and
> > .gcc_except_table (or .rodata for broken ppc compilers). Changing
> > garbage collection to process .rela.eh_frame thus runs into the problem
> > of distinguishing the two types of reloc: You need to ignore the
> > former, and mark sections for the latter.
>
> That's exactly what I proposed in my last message, but I suggested passing a
Sorry, I was just going by memory.
> parameter to _bfd_elf_gc_mark to make it "forget" code sections. It seems
> autodetecting .eh_frame is more straightforward.
>
> > Try the following totally untested patch.
> >
> > * elflink.c (_bfd_elf_gc_mark): Handle .eh_frame relocs specially..
> > (bfd_elf_gc_sections): ..rather than totally ignoring .eh_frame.
> > Don't recheck sections we have already marked.
>
> I think it doesn't work (alone) either, because you unconditionally mark
> all .gcc_except_table* sections, which themselves point to the functions.
That doesn't make any difference, because .gcc_except_table* is marked
via KEEP() in the linker script. So I don't think you need anything
more than the patch I posted.
--
Alan Modra
IBM OzLabs - Linux Technology Centre
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: gc sections and .eh_frame
2005-06-28 2:58 ` Alan Modra
@ 2005-06-28 7:40 ` Eric Botcazou
2005-06-28 11:42 ` Alan Modra
0 siblings, 1 reply; 50+ messages in thread
From: Eric Botcazou @ 2005-06-28 7:40 UTC (permalink / raw)
To: Alan Modra; +Cc: binutils, Jonathan Larmour
> > I think it doesn't work (alone) either, because you unconditionally mark
> > all .gcc_except_table* sections, which themselves point to the functions.
>
> That doesn't make any difference, because .gcc_except_table* is marked
> via KEEP() in the linker script. So I don't think you need anything
> more than the patch I posted.
That's not quite true, .gcc_except_table is indeed marked as KEEP, but
not .gcc_except_table.* :-)
That's the crux of the mechanism: an unpatched (non broken) compiler will only
emit .gcc_except_table. But a patched compiler (i.e. the AdaCore compiler or
the FSF compiler + http://gcc.gnu.org/ml/gcc-patches/2004-03/msg01433.html)
will emit .gcc_except_table.* with -ffunction-sections, making it possible to
have a working --gc-sections for languages with EH.
--
Eric Botcazou
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: gc sections and .eh_frame
2005-06-28 7:40 ` Eric Botcazou
@ 2005-06-28 11:42 ` Alan Modra
2005-06-28 11:58 ` Eric Botcazou
0 siblings, 1 reply; 50+ messages in thread
From: Alan Modra @ 2005-06-28 11:42 UTC (permalink / raw)
To: Eric Botcazou; +Cc: binutils, Jonathan Larmour
On Tue, Jun 28, 2005 at 09:40:28AM +0200, Eric Botcazou wrote:
> That's not quite true, .gcc_except_table is indeed marked as KEEP, but
> not .gcc_except_table.* :-)
So how do you ensure .gcc_except_table.* is marked, if not by looking
through .eh_frame relocs?
--
Alan Modra
IBM OzLabs - Linux Technology Centre
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: gc sections and .eh_frame
2005-06-28 11:42 ` Alan Modra
@ 2005-06-28 11:58 ` Eric Botcazou
2005-06-29 1:24 ` Alan Modra
0 siblings, 1 reply; 50+ messages in thread
From: Eric Botcazou @ 2005-06-28 11:58 UTC (permalink / raw)
To: Alan Modra; +Cc: binutils, Jonathan Larmour
> So how do you ensure .gcc_except_table.* is marked, if not by looking
> through .eh_frame relocs?
Take a look at the change to output_function_exception_table in the
aforementioned GCC patch. :-)
--
Eric Botcazou
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: gc sections and .eh_frame
2005-06-28 11:58 ` Eric Botcazou
@ 2005-06-29 1:24 ` Alan Modra
2005-06-29 6:52 ` Eric Botcazou
2005-06-29 13:54 ` Alan Modra
0 siblings, 2 replies; 50+ messages in thread
From: Alan Modra @ 2005-06-29 1:24 UTC (permalink / raw)
To: Eric Botcazou; +Cc: binutils, Jonathan Larmour
On Tue, Jun 28, 2005 at 01:57:58PM +0200, Eric Botcazou wrote:
> > So how do you ensure .gcc_except_table.* is marked, if not by looking
> > through .eh_frame relocs?
>
> Take a look at the change to output_function_exception_table in the
> aforementioned GCC patch. :-)
I see. That extra word emitted just to tie .gcc_except_table.* to the
function code is no doubt one reason why the gcc patch hasn't been
approved. Hmm, I think we can do without it by marking sections
referenced from .eh_frame specially, and keeping them iff the associated
.text section is marked. Patch in progress.
--
Alan Modra
IBM OzLabs - Linux Technology Centre
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: gc sections and .eh_frame
2005-06-29 1:24 ` Alan Modra
@ 2005-06-29 6:52 ` Eric Botcazou
2005-06-29 12:45 ` Jonathan Larmour
2005-06-29 13:54 ` Alan Modra
1 sibling, 1 reply; 50+ messages in thread
From: Eric Botcazou @ 2005-06-29 6:52 UTC (permalink / raw)
To: Alan Modra; +Cc: binutils, Jonathan Larmour
> I see. That extra word emitted just to tie .gcc_except_table.* to the
> function code is no doubt one reason why the gcc patch hasn't been
> approved.
The official reason was that COMDAT groups had been introduced in-between and
that the patch should be rewritten to use them. On my list, but very, very
low-priority given the very, very low interest for this stuff outside the Ada
world.
> Hmm, I think we can do without it by marking sections referenced
> from .eh_frame specially, and keeping them iff the associated
> .text section is marked. Patch in progress.
That would be a nice improvement. I could try to propose an updated version
of the GCC patch before the end of Stage 2 if you came up with something for
the linker.
In the meantime, do you want me to apply the patch on Binutils mainline? On
Binutils 2.16 branch?
--
Eric Botcazou
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: gc sections and .eh_frame
2005-06-29 6:52 ` Eric Botcazou
@ 2005-06-29 12:45 ` Jonathan Larmour
0 siblings, 0 replies; 50+ messages in thread
From: Jonathan Larmour @ 2005-06-29 12:45 UTC (permalink / raw)
To: Eric Botcazou; +Cc: Alan Modra, binutils
Eric Botcazou wrote:
>
> In the meantime, do you want me to apply the patch on Binutils mainline? On
> Binutils 2.16 branch?
So should I try out the patch Eric sent on the 27th 12:55 to check it
works as expected? Is that the final version?
Jifl
--
eCosCentric http://www.eCosCentric.com/ The eCos and RedBoot experts
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: gc sections and .eh_frame
2005-06-29 1:24 ` Alan Modra
2005-06-29 6:52 ` Eric Botcazou
@ 2005-06-29 13:54 ` Alan Modra
2005-06-29 22:31 ` Jonathan Larmour
2005-07-26 11:30 ` Alan Modra
1 sibling, 2 replies; 50+ messages in thread
From: Alan Modra @ 2005-06-29 13:54 UTC (permalink / raw)
To: Eric Botcazou, binutils, Jonathan Larmour
On Wed, Jun 29, 2005 at 10:54:01AM +0930, Alan Modra wrote:
> I think we can do without it by marking sections
> referenced from .eh_frame specially, and keeping them iff the associated
> .text section is marked.
Committing mainline.
bfd/
* elflink.c (_bfd_elf_gc_mark): Mark sections referenced by
.eh_frame specially..
(bfd_elf_gc_sections): ..rather than totally ignoring .eh_frame.
Don't recheck sections we have already marked.
(elf_gc_sweep): Keep non-code sections referenced from .eh_frame.
* section.c (struct bfd_section): Add gc_mark_from_eh.
(STD_SECTION): Adjust.
* ecoff.c (bfd_debug_section): Adjust.
* bfd-in2.h: Regenerate.
ld/
* scripttempl/elf.sc (.gcc_except_table): Don't KEEP.
Index: bfd/elflink.c
===================================================================
RCS file: /cvs/src/src/bfd/elflink.c,v
retrieving revision 1.168
diff -u -p -r1.168 elflink.c
--- bfd/elflink.c 14 Jun 2005 19:25:45 -0000 1.168
+++ bfd/elflink.c 29 Jun 2005 13:02:15 -0000
@@ -8733,6 +8733,7 @@ _bfd_elf_gc_mark (struct bfd_link_info *
gc_mark_hook_fn gc_mark_hook)
{
bfd_boolean ret;
+ bfd_boolean is_eh;
asection *group_sec;
sec->gc_mark = 1;
@@ -8745,6 +8746,7 @@ _bfd_elf_gc_mark (struct bfd_link_info *
/* Look through the section relocs. */
ret = TRUE;
+ is_eh = strcmp (sec->name, ".eh_frame") == 0;
if ((sec->flags & SEC_RELOC) != 0 && sec->reloc_count > 0)
{
Elf_Internal_Rela *relstart, *rel, *relend;
@@ -8821,6 +8823,8 @@ _bfd_elf_gc_mark (struct bfd_link_info *
{
if (bfd_get_flavour (rsec->owner) != bfd_target_elf_flavour)
rsec->gc_mark = 1;
+ else if (is_eh)
+ rsec->gc_mark_from_eh = 1;
else if (!_bfd_elf_gc_mark (info, rsec, gc_mark_hook))
{
ret = FALSE;
@@ -8891,6 +8895,41 @@ elf_gc_sweep (struct bfd_link_info *info
if (o->gc_mark)
continue;
+ /* Keep .gcc_except_table.* if the associated .text.* is
+ marked. This isn't very nice, but the proper solution,
+ splitting .eh_frame up and using comdat doesn't pan out
+ easily due to needing special relocs to handle the
+ difference of two symbols in separate sections.
+ Don't keep code sections referenced by .eh_frame. */
+ if (o->gc_mark_from_eh && (o->flags & SEC_CODE) == 0)
+ {
+ if (strncmp (o->name, ".gcc_except_table.", 18) == 0)
+ {
+ unsigned long len;
+ char *fn_name;
+ asection *fn_text;
+
+ len = strlen (o->name + 18) + 1;
+ fn_name = bfd_malloc (len + 6);
+ if (fn_name == NULL)
+ return FALSE;
+ memcpy (fn_name, ".text.", 6);
+ memcpy (fn_name + 6, o->name + 18, len);
+ fn_text = bfd_get_section_by_name (sub, fn_name);
+ free (fn_name);
+ if (fn_text != NULL && fn_text->gc_mark)
+ o->gc_mark = 1;
+ }
+
+ /* If not using specially named exception table section,
+ then keep whatever we are using. */
+ else
+ o->gc_mark = 1;
+
+ if (o->gc_mark)
+ continue;
+ }
+
/* Skip sweeping sections already excluded. */
if (o->flags & SEC_EXCLUDE)
continue;
@@ -9123,18 +9164,9 @@ bfd_elf_gc_sections (bfd *abfd, struct b
continue;
for (o = sub->sections; o != NULL; o = o->next)
- {
- if (o->flags & SEC_KEEP)
- {
- /* _bfd_elf_discard_section_eh_frame knows how to discard
- orphaned FDEs so don't mark sections referenced by the
- EH frame section. */
- if (strcmp (o->name, ".eh_frame") == 0)
- o->gc_mark = 1;
- else if (!_bfd_elf_gc_mark (info, o, gc_mark_hook))
- return FALSE;
- }
- }
+ if ((o->flags & SEC_KEEP) != 0 && !o->gc_mark)
+ if (!_bfd_elf_gc_mark (info, o, gc_mark_hook))
+ return FALSE;
}
/* ... and mark SEC_EXCLUDE for those that go. */
Index: bfd/section.c
===================================================================
RCS file: /cvs/src/src/bfd/section.c,v
retrieving revision 1.88
diff -u -p -r1.88 section.c
--- bfd/section.c 17 May 2005 19:44:55 -0000 1.88
+++ bfd/section.c 29 Jun 2005 13:02:16 -0000
@@ -354,8 +354,9 @@ CODE_FRAGMENT
. output sections that have an input section. *}
. unsigned int linker_has_input : 1;
.
-. {* A mark flag used by some linker backends for garbage collection. *}
+. {* Mark flags used by some linker backends for garbage collection. *}
. unsigned int gc_mark : 1;
+. unsigned int gc_mark_from_eh : 1;
.
. {* The following flags are used by the ELF linker. *}
.
@@ -661,18 +662,18 @@ static const asymbol global_syms[] =
#define STD_SECTION(SEC, FLAGS, SYM, NAME, IDX) \
const asymbol * const SYM = (asymbol *) &global_syms[IDX]; \
- asection SEC = \
+ asection SEC = \
/* name, id, index, next, prev, flags, user_set_vma, */ \
{ NAME, IDX, 0, NULL, NULL, FLAGS, 0, \
\
- /* linker_mark, linker_has_input, gc_mark, segment_mark, */ \
+ /* linker_mark, linker_has_input, gc_mark, gc_mark_from_eh, */ \
0, 0, 1, 0, \
\
- /* sec_info_type, use_rela_p, has_tls_reloc, has_gp_reloc, */ \
- 0, 0, 0, 0, \
+ /* segment_mark, sec_info_type, use_rela_p, has_tls_reloc, */ \
+ 0, 0, 0, 0, \
\
- /* need_finalize_relax, reloc_done, */ \
- 0, 0, \
+ /* has_gp_reloc, need_finalize_relax, reloc_done, */ \
+ 0, 0, 0, \
\
/* vma, lma, size, rawsize */ \
0, 0, 0, 0, \
@@ -686,8 +687,8 @@ static const asymbol global_syms[] =
/* line_filepos, userdata, contents, lineno, lineno_count, */ \
0, NULL, NULL, NULL, 0, \
\
- /* entsize, kept_section, moving_line_filepos, */ \
- 0, NULL, 0, \
+ /* entsize, kept_section, moving_line_filepos, */ \
+ 0, NULL, 0, \
\
/* target_index, used_by_bfd, constructor_chain, owner, */ \
0, NULL, NULL, NULL, \
Index: bfd/ecoff.c
===================================================================
RCS file: /cvs/src/src/bfd/ecoff.c,v
retrieving revision 1.45
diff -u -p -r1.45 ecoff.c
--- bfd/ecoff.c 4 May 2005 15:53:07 -0000 1.45
+++ bfd/ecoff.c 29 Jun 2005 13:02:04 -0000
@@ -54,12 +54,12 @@ static asection bfd_debug_section =
{
/* name, id, index, next, prev, flags, user_set_vma, */
"*DEBUG*", 0, 0, NULL, NULL, 0, 0,
- /* linker_mark, linker_has_input, gc_mark, segment_mark, */
- 0, 0, 0, 0,
- /* sec_info_type, use_rela_p, has_tls_reloc, has_gp_reloc, */
- 0, 0, 0, 0,
- /* need_finalize_relax, reloc_done, */
- 0, 0,
+ /* linker_mark, linker_has_input, gc_mark, gc_mark_from_eh, */
+ 0, 0, 1, 0,
+ /* segment_mark, sec_info_type, use_rela_p, has_tls_reloc, */
+ 0, 0, 0, 0,
+ /* has_gp_reloc, need_finalize_relax, reloc_done, */
+ 0, 0, 0,
/* vma, lma, size, rawsize, */
0, 0, 0, 0,
/* output_offset, output_section, alignment_power, */
@@ -68,7 +68,7 @@ static asection bfd_debug_section =
NULL, NULL, 0, 0, 0,
/* line_filepos, userdata, contents, lineno, lineno_count, */
0, NULL, NULL, NULL, 0,
- /* entsize, kept_section, moving_line_filepos, */
+ /* entsize, kept_section, moving_line_filepos, */
0, NULL, 0,
/* target_index, used_by_bfd, constructor_chain, owner, */
0, NULL, NULL, NULL,
Index: ld/scripttempl/elf.sc
===================================================================
RCS file: /cvs/src/src/ld/scripttempl/elf.sc,v
retrieving revision 1.59
diff -u -p -r1.59 elf.sc
--- ld/scripttempl/elf.sc 10 Jun 2005 00:39:56 -0000 1.59
+++ ld/scripttempl/elf.sc 29 Jun 2005 13:02:21 -0000
@@ -329,7 +329,7 @@ cat <<EOF
${OTHER_READONLY_SECTIONS}
.eh_frame_hdr : { *(.eh_frame_hdr) }
.eh_frame ${RELOCATING-0} : ONLY_IF_RO { KEEP (*(.eh_frame)) }
- .gcc_except_table ${RELOCATING-0} : ONLY_IF_RO { KEEP (*(.gcc_except_table)) *(.gcc_except_table.*) }
+ .gcc_except_table ${RELOCATING-0} : ONLY_IF_RO { *(.gcc_except_table .gcc_except_table.*) }
/* Adjust the address for the data segment. We want to adjust up to
the same address within the page on the next page up. */
@@ -339,7 +339,7 @@ cat <<EOF
/* Exception handling */
.eh_frame ${RELOCATING-0} : ONLY_IF_RW { KEEP (*(.eh_frame)) }
- .gcc_except_table ${RELOCATING-0} : ONLY_IF_RW { KEEP (*(.gcc_except_table)) *(.gcc_except_table.*) }
+ .gcc_except_table ${RELOCATING-0} : ONLY_IF_RW { *(.gcc_except_table .gcc_except_table.*) }
/* Thread Local Storage sections */
.tdata ${RELOCATING-0} : { *(.tdata${RELOCATING+ .tdata.* .gnu.linkonce.td.*}) }
--
Alan Modra
IBM OzLabs - Linux Technology Centre
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: gc sections and .eh_frame
2005-06-29 13:54 ` Alan Modra
@ 2005-06-29 22:31 ` Jonathan Larmour
2005-06-30 22:28 ` Alan Modra
2005-07-26 11:30 ` Alan Modra
1 sibling, 1 reply; 50+ messages in thread
From: Jonathan Larmour @ 2005-06-29 22:31 UTC (permalink / raw)
To: Alan Modra; +Cc: Eric Botcazou, binutils
Alan Modra wrote:
> On Wed, Jun 29, 2005 at 10:54:01AM +0930, Alan Modra wrote:
>
>>I think we can do without it by marking sections
>>referenced from .eh_frame specially, and keeping them iff the associated
>>.text section is marked.
>
>
> Committing mainline.
>
> bfd/
> * elflink.c (_bfd_elf_gc_mark): Mark sections referenced by
> .eh_frame specially..
> (bfd_elf_gc_sections): ..rather than totally ignoring .eh_frame.
> Don't recheck sections we have already marked.
> (elf_gc_sweep): Keep non-code sections referenced from .eh_frame.
> * section.c (struct bfd_section): Add gc_mark_from_eh.
> (STD_SECTION): Adjust.
> * ecoff.c (bfd_debug_section): Adjust.
> * bfd-in2.h: Regenerate.
>
> ld/
> * scripttempl/elf.sc (.gcc_except_table): Don't KEEP.
I updated my sources to current binutils CVS and rebuuilt my
powerpc-eabi-ld. Unfortunately I now get the following when linking an
application that uses C++ exceptions:
`DW.ref._ZTISt9exception' referenced in section `.rodata' of
/local/builds/toolchains/powerpc-eabi/tools/lib/gcc/powerpc-eabi/3.4.4/../../../../powerpc-eabi/lib/nof/libsupc++.a(vterminate.o):
defined in discarded section `.gnu.linkonce.s.DW.ref._ZTISt9exception' of
/local/builds/toolchains/powerpc-eabi/tools/lib/gcc/powerpc-eabi/3.4.4/../../../../powerpc-eabi/lib/nof/libsupc++.a(vterminate.o)collect2:
ld returned 1 exit status
I'll have a closer look tomorrow, although my hunch is that it's something
to do with being a .gnu.linkonce section specifically - possibly there are
multiple instances of that section name, and only one is marked to be
kept, but when duplicate .gnu.linkonce sections are removed, it is the
other instance that is kept, and later when GC happens, even that one is
removed.
Jifl
--
eCosCentric http://www.eCosCentric.com/ The eCos and RedBoot experts
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: gc sections and .eh_frame
2005-06-29 22:31 ` Jonathan Larmour
@ 2005-06-30 22:28 ` Alan Modra
2005-07-01 13:31 ` Jonathan Larmour
0 siblings, 1 reply; 50+ messages in thread
From: Alan Modra @ 2005-06-30 22:28 UTC (permalink / raw)
To: Jonathan Larmour; +Cc: Eric Botcazou, binutils
On Wed, Jun 29, 2005 at 11:31:02PM +0100, Jonathan Larmour wrote:
> I updated my sources to current binutils CVS and rebuuilt my
> powerpc-eabi-ld. Unfortunately I now get the following when linking an
> application that uses C++ exceptions:
> `DW.ref._ZTISt9exception' referenced in section `.rodata' of
> /local/builds/toolchains/powerpc-eabi/tools/lib/gcc/powerpc-eabi/3.4.4/../../../../powerpc-eabi/lib/nof/libsupc++.a(vterminate.o):
> defined in discarded section `.gnu.linkonce.s.DW.ref._ZTISt9exception' of
> /local/builds/toolchains/powerpc-eabi/tools/lib/gcc/powerpc-eabi/3.4.4/../../../../powerpc-eabi/lib/nof/libsupc++.a(vterminate.o)collect2:
> ld returned 1 exit status
>
> I'll have a closer look tomorrow, although my hunch is that it's something
> to do with being a .gnu.linkonce section specifically - possibly there are
Yes.
> multiple instances of that section name, and only one is marked to be
> kept, but when duplicate .gnu.linkonce sections are removed, it is the
> other instance that is kept, and later when GC happens, even that one is
> removed.
No, GC isn't removing too many sections. The problem is that .eh_frame,
.gcc_exception_table, debug sections, and other sections on some targets
are not split per-function. When linkonce sections are removed, you are
left with references from these sections to the removed sections. The
linker knows this happens for certain section names, so doesn't warn,
but powerpc has been using .rodata instead of .gcc_exception_table..
A workaround is to link with --noinhibit-exec.
--
Alan Modra
IBM OzLabs - Linux Technology Centre
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: gc sections and .eh_frame
2005-06-30 22:28 ` Alan Modra
@ 2005-07-01 13:31 ` Jonathan Larmour
2005-07-04 4:50 ` Alan Modra
0 siblings, 1 reply; 50+ messages in thread
From: Jonathan Larmour @ 2005-07-01 13:31 UTC (permalink / raw)
To: Alan Modra; +Cc: Eric Botcazou, binutils
Alan Modra wrote:
> On Wed, Jun 29, 2005 at 11:31:02PM +0100, Jonathan Larmour wrote:
>
>>I updated my sources to current binutils CVS and rebuuilt my
>>powerpc-eabi-ld. Unfortunately I now get the following when linking an
>>application that uses C++ exceptions:
>>`DW.ref._ZTISt9exception' referenced in section `.rodata' of
>>/local/builds/toolchains/powerpc-eabi/tools/lib/gcc/powerpc-eabi/3.4.4/../../../../powerpc-eabi/lib/nof/libsupc++.a(vterminate.o):
>>defined in discarded section `.gnu.linkonce.s.DW.ref._ZTISt9exception' of
>>/local/builds/toolchains/powerpc-eabi/tools/lib/gcc/powerpc-eabi/3.4.4/../../../../powerpc-eabi/lib/nof/libsupc++.a(vterminate.o)collect2:
>>ld returned 1 exit status
[snip]
>>multiple instances of that section name, and only one is marked to be
>>kept, but when duplicate .gnu.linkonce sections are removed, it is the
>>other instance that is kept, and later when GC happens, even that one is
>>removed.
>
>
> No, GC isn't removing too many sections. The problem is that .eh_frame,
> .gcc_exception_table, debug sections, and other sections on some targets
> are not split per-function. When linkonce sections are removed, you are
> left with references from these sections to the removed sections. The
> linker knows this happens for certain section names, so doesn't warn,
> but powerpc has been using .rodata instead of .gcc_exception_table..
Thanks for the explanation. I see that now.
Unfortunately it doesn't leave any sysv4 powerpc target users (including
powerpc-linux as you said before) much better off, since the GCC change to
stop using .rodata hasn't even been committed to the trunk yet, nevermind
any current release branches, and won't be widely disseminated until a
while after that. Well, they're slightly better off since at least they
now get an error rather than silent failure :-).
But I've even less of an idea of how this could be addressed in binutils.
The only way I can think of to identify the problematic powerpc GCC is the
presence of .eh_frame with an absence of .gcc_except_table, and putting
that knowledge in place in elf_link_input_bfd is a bit of a kludge. Any
other ideas?
> A workaround is to link with --noinhibit-exec.
Ick. I'm sure we should be recommending something better than that.
Jifl
--
eCosCentric http://www.eCosCentric.com/ The eCos and RedBoot experts
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: gc sections and .eh_frame
2005-07-01 13:31 ` Jonathan Larmour
@ 2005-07-04 4:50 ` Alan Modra
2005-07-04 10:55 ` Jonathan Larmour
0 siblings, 1 reply; 50+ messages in thread
From: Alan Modra @ 2005-07-04 4:50 UTC (permalink / raw)
To: Jonathan Larmour; +Cc: Eric Botcazou, binutils
On Fri, Jul 01, 2005 at 02:31:44PM +0100, Jonathan Larmour wrote:
> >A workaround is to link with --noinhibit-exec.
>
> Ick. I'm sure we should be recommending something better than that.
The reason I haven't worried too much is that --gc-sections doing
anything on dynamic executables is a relatively new feature.
--
Alan Modra
IBM OzLabs - Linux Technology Centre
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: gc sections and .eh_frame
2005-07-04 4:50 ` Alan Modra
@ 2005-07-04 10:55 ` Jonathan Larmour
0 siblings, 0 replies; 50+ messages in thread
From: Jonathan Larmour @ 2005-07-04 10:55 UTC (permalink / raw)
To: Alan Modra; +Cc: Eric Botcazou, binutils
Alan Modra wrote:
> On Fri, Jul 01, 2005 at 02:31:44PM +0100, Jonathan Larmour wrote:
>
>>>A workaround is to link with --noinhibit-exec.
>>
>>Ick. I'm sure we should be recommending something better than that.
>
>
> The reason I haven't worried too much is that --gc-sections doing
> anything on dynamic executables is a relatively new feature.
Ah well, we (the eCos project), have been using it on static builds for
embedded targets since before it was publically released (it was written
for us) :-). 1998 I think. powerpc-eabi was one of the first.
Jifl
--
eCosCentric http://www.eCosCentric.com/ The eCos and RedBoot experts
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: gc sections and .eh_frame
2005-06-29 13:54 ` Alan Modra
2005-06-29 22:31 ` Jonathan Larmour
@ 2005-07-26 11:30 ` Alan Modra
2005-07-26 12:05 ` Alan Modra
2005-08-25 0:06 ` Jim Blandy
1 sibling, 2 replies; 50+ messages in thread
From: Alan Modra @ 2005-07-26 11:30 UTC (permalink / raw)
To: binutils
I've been playing with enabling gc-sections for shared libs, and hit
a problem with the way .gcc_except_table is handled. We were keeping
.gcc_except_table itself, but not sections referenced from there.
* elflink.c (elf_gc_sweep): Move gcc_except_table code..
(bfd_elf_gc_sections): ..to here.
Index: bfd/elflink.c
===================================================================
RCS file: /cvs/src/src/bfd/elflink.c,v
retrieving revision 1.179
diff -u -p -r1.179 elflink.c
--- bfd/elflink.c 25 Jul 2005 15:35:37 -0000 1.179
+++ bfd/elflink.c 26 Jul 2005 10:58:51 -0000
@@ -8912,41 +8912,6 @@ elf_gc_sweep (struct bfd_link_info *info
if (o->gc_mark)
continue;
- /* Keep .gcc_except_table.* if the associated .text.* is
- marked. This isn't very nice, but the proper solution,
- splitting .eh_frame up and using comdat doesn't pan out
- easily due to needing special relocs to handle the
- difference of two symbols in separate sections.
- Don't keep code sections referenced by .eh_frame. */
- if (o->gc_mark_from_eh && (o->flags & SEC_CODE) == 0)
- {
- if (strncmp (o->name, ".gcc_except_table.", 18) == 0)
- {
- unsigned long len;
- char *fn_name;
- asection *fn_text;
-
- len = strlen (o->name + 18) + 1;
- fn_name = bfd_malloc (len + 6);
- if (fn_name == NULL)
- return FALSE;
- memcpy (fn_name, ".text.", 6);
- memcpy (fn_name + 6, o->name + 18, len);
- fn_text = bfd_get_section_by_name (sub, fn_name);
- free (fn_name);
- if (fn_text != NULL && fn_text->gc_mark)
- o->gc_mark = 1;
- }
-
- /* If not using specially named exception table section,
- then keep whatever we are using. */
- else
- o->gc_mark = 1;
-
- if (o->gc_mark)
- continue;
- }
-
/* Skip sweeping sections already excluded. */
if (o->flags & SEC_EXCLUDE)
continue;
@@ -9183,6 +9151,48 @@ bfd_elf_gc_sections (bfd *abfd, struct b
return FALSE;
}
+ /* ... again for sections marked from eh_frame. */
+ for (sub = info->input_bfds; sub != NULL; sub = sub->link_next)
+ {
+ asection *o;
+
+ if (bfd_get_flavour (sub) != bfd_target_elf_flavour)
+ continue;
+
+ /* Keep .gcc_except_table.* if the associated .text.* is
+ marked. This isn't very nice, but the proper solution,
+ splitting .eh_frame up and using comdat doesn't pan out
+ easily due to needing special relocs to handle the
+ difference of two symbols in separate sections.
+ Don't keep code sections referenced by .eh_frame. */
+ for (o = sub->sections; o != NULL; o = o->next)
+ if (!o->gc_mark && o->gc_mark_from_eh && (o->flags & SEC_CODE) == 0)
+ {
+ if (strncmp (o->name, ".gcc_except_table.", 18) == 0)
+ {
+ unsigned long len;
+ char *fn_name;
+ asection *fn_text;
+
+ len = strlen (o->name + 18) + 1;
+ fn_name = bfd_malloc (len + 6);
+ if (fn_name == NULL)
+ return FALSE;
+ memcpy (fn_name, ".text.", 6);
+ memcpy (fn_name + 6, o->name + 18, len);
+ fn_text = bfd_get_section_by_name (sub, fn_name);
+ free (fn_name);
+ if (fn_text == NULL || !fn_text->gc_mark)
+ continue;
+ }
+
+ /* If not using specially named exception table section,
+ then keep whatever we are using. */
+ if (!_bfd_elf_gc_mark (info, o, gc_mark_hook))
+ return FALSE;
+ }
+ }
+
/* ... and mark SEC_EXCLUDE for those that go. */
if (!elf_gc_sweep (info, get_elf_backend_data (abfd)->gc_sweep_hook))
return FALSE;
--
Alan Modra
IBM OzLabs - Linux Technology Centre
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: gc sections and .eh_frame
2005-07-26 11:30 ` Alan Modra
@ 2005-07-26 12:05 ` Alan Modra
2005-08-25 0:06 ` Jim Blandy
1 sibling, 0 replies; 50+ messages in thread
From: Alan Modra @ 2005-07-26 12:05 UTC (permalink / raw)
To: binutils
On Tue, Jul 26, 2005 at 08:59:47PM +0930, Alan Modra wrote:
> I've been playing with enabling gc-sections for shared libs, and hit
> a problem with the way .gcc_except_table is handled. We were keeping
> .gcc_except_table itself, but not sections referenced from there.
I should have said that this problem likely affects dynamic apps too.
The code to do gc-sections when building shared libs is like this:
* elflink.c (elf_gc_mark_dynamic_ref_symbol): Handle -shared.
(bfd_elf_gc_sections): Allow -gc-sections when -shared.
* elf32-ppc.c (ppc_elf_gc_sweep_hook): Correct for -shared.
Index: bfd/elflink.c
===================================================================
RCS file: /cvs/src/src/bfd/elflink.c,v
retrieving revision 1.179
diff -u -p -r1.179 elflink.c
--- bfd/elflink.c 25 Jul 2005 15:35:37 -0000 1.179
+++ bfd/elflink.c 26 Jul 2005 10:58:51 -0000
@@ -9107,19 +9072,25 @@ elf_gc_smash_unused_vtentry_relocs (stru
return TRUE;
}
-/* Mark sections containing dynamically referenced symbols. This is called
- through elf_link_hash_traverse. */
+/* Mark sections containing dynamically referenced symbols. When
+ building shared libraries, we must assume that any visible symbol is
+ referenced. */
static bfd_boolean
-elf_gc_mark_dynamic_ref_symbol (struct elf_link_hash_entry *h,
- void *okp ATTRIBUTE_UNUSED)
+elf_gc_mark_dynamic_ref_symbol (struct elf_link_hash_entry *h, void *inf)
{
+ struct bfd_link_info *info = (struct bfd_link_info *) inf;
+
if (h->root.type == bfd_link_hash_warning)
h = (struct elf_link_hash_entry *) h->root.u.i.link;
if ((h->root.type == bfd_link_hash_defined
|| h->root.type == bfd_link_hash_defweak)
- && h->ref_dynamic)
+ && (h->ref_dynamic
+ || (info->shared
+ && h->def_regular
+ && ELF_ST_VISIBILITY (h->other) != STV_INTERNAL
+ && ELF_ST_VISIBILITY (h->other) != STV_HIDDEN)))
h->root.u.def.section->flags |= SEC_KEEP;
return TRUE;
@@ -9139,7 +9110,6 @@ bfd_elf_gc_sections (bfd *abfd, struct b
if (!get_elf_backend_data (abfd)->can_gc_sections
|| info->relocatable
|| info->emitrelocations
- || info->shared
|| !is_elf_hash_table (info->hash))
{
(*_bfd_error_handler)(_("Warning: gc-sections option ignored"));
@@ -9164,9 +9134,7 @@ bfd_elf_gc_sections (bfd *abfd, struct b
if (elf_hash_table (info)->dynamic_sections_created)
elf_link_hash_traverse (elf_hash_table (info),
elf_gc_mark_dynamic_ref_symbol,
- &ok);
- if (!ok)
- return FALSE;
+ info);
/* Grovel through relocs to find out who stays ... */
gc_mark_hook = get_elf_backend_data (abfd)->gc_mark_hook;
Index: bfd/elf32-ppc.c
===================================================================
RCS file: /cvs/src/src/bfd/elf32-ppc.c,v
retrieving revision 1.174
diff -u -p -r1.174 elf32-ppc.c
--- bfd/elf32-ppc.c 16 Jul 2005 03:30:23 -0000 1.174
+++ bfd/elf32-ppc.c 26 Jul 2005 10:58:46 -0000
@@ -3728,8 +3778,12 @@ ppc_elf_gc_sweep_hook (bfd *abfd,
case R_PPC_ADDR14_BRNTAKEN:
case R_PPC_UADDR32:
case R_PPC_UADDR16:
+ if (info->shared)
+ break;
+
case R_PPC_PLT32:
case R_PPC_PLTREL24:
+ case R_PPC_PLTREL32:
case R_PPC_PLT16_LO:
case R_PPC_PLT16_HI:
case R_PPC_PLT16_HA:
--
Alan Modra
IBM OzLabs - Linux Technology Centre
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: gc sections and .eh_frame
2005-07-26 11:30 ` Alan Modra
2005-07-26 12:05 ` Alan Modra
@ 2005-08-25 0:06 ` Jim Blandy
2005-08-25 0:48 ` Alan Modra
1 sibling, 1 reply; 50+ messages in thread
From: Jim Blandy @ 2005-08-25 0:06 UTC (permalink / raw)
To: binutils
Alan Modra <amodra@bigpond.net.au> writes:
> I've been playing with enabling gc-sections for shared libs, and hit
> a problem with the way .gcc_except_table is handled. We were keeping
> .gcc_except_table itself, but not sections referenced from there.
If I'm understanding the whole saga here correctly, then one way of
describing what makes section GC interact with exception tables so
oddly is that the relocs point backwards from the way they normally
do.
That is, normally, if the GC keeps some section A, and A has relocs
referring to (symbols defined in) some section B, then the GC should
also keep B. Conversely, if there are no kept sections with relocs
referring to B, then B should be dropped.
For exception handling tables, however, the relocs point in the
opposite direction: if the GC keeps some code section A, and some
exception table B has relocs referring to A, then the GC should also
keep B. Conversely, if there are no kept code sections that an
exception table B has relocs referring to, then B should be dropped.
Not that folks don't already know this; I just thought it was a
helpfully clear way to describe things.
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: gc sections and .eh_frame
2005-08-25 0:06 ` Jim Blandy
@ 2005-08-25 0:48 ` Alan Modra
0 siblings, 0 replies; 50+ messages in thread
From: Alan Modra @ 2005-08-25 0:48 UTC (permalink / raw)
To: Jim Blandy; +Cc: binutils
On Wed, Aug 24, 2005 at 05:04:48PM -0700, Jim Blandy wrote:
> That is, normally, if the GC keeps some section A, and A has relocs
> referring to (symbols defined in) some section B, then the GC should
> also keep B. Conversely, if there are no kept sections with relocs
> referring to B, then B should be dropped.
Yes, and yes.
> For exception handling tables, however, the relocs point in the
> opposite direction: if the GC keeps some code section A, and some
> exception table B has relocs referring to A, then the GC should also
> keep B. Conversely, if there are no kept code sections that an
> exception table B has relocs referring to, then B should be dropped.
No. gc marking of sections referenced from .gcc_except_table* should be
as for any other section. If we had per-function .eh_frame sections
then there wouldn't be anything special at all about .eh_frame* and
.gcc_except_table*. ie. relocs in .eh_frame* would reference
.gcc_except_table*. The trouble is that we have a monolithic .eh_frame,
so we can't treat its relocs normally (and we can't break up .eh_frame
easily, but that's another story).
--
Alan Modra
IBM OzLabs - Linux Technology Centre
^ permalink raw reply [flat|nested] 50+ messages in thread
end of thread, other threads:[~2005-08-25 0:48 UTC | newest]
Thread overview: 50+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-06-07 17:48 gc sections and .eh_frame Jonathan Larmour
2005-06-07 18:00 ` Eric Botcazou
2005-06-07 18:11 ` Jonathan Larmour
2005-06-08 2:09 ` Alan Modra
2005-06-08 11:13 ` Jonathan Larmour
2005-06-08 19:10 ` Richard Henderson
2005-06-08 19:29 ` Jonathan Larmour
2005-06-08 19:32 ` Richard Henderson
2005-06-08 21:36 ` Jonathan Larmour
2005-06-08 22:02 ` Richard Henderson
2005-06-09 10:33 ` Jonathan Larmour
2005-06-09 11:38 ` Eric Botcazou
2005-06-09 12:07 ` Jonathan Larmour
2005-06-09 12:49 ` Alan Modra
2005-06-09 13:02 ` Eric Botcazou
2005-06-09 13:50 ` Jonathan Larmour
2005-06-09 14:22 ` Eric Botcazou
2005-06-09 14:33 ` Jonathan Larmour
2005-06-10 4:23 ` Alan Modra
2005-06-10 6:46 ` Eric Botcazou
2005-06-10 11:49 ` Jonathan Larmour
2005-06-10 11:55 ` Eric Botcazou
2005-06-10 12:09 ` Alan Modra
2005-06-10 12:51 ` Jonathan Larmour
2005-06-10 13:44 ` Eric Botcazou
2005-06-10 14:26 ` Jonathan Larmour
2005-06-10 14:50 ` Eric Botcazou
2005-06-10 14:58 ` Jonathan Larmour
2005-06-10 15:13 ` Eric Botcazou
2005-06-22 11:46 ` Jonathan Larmour
2005-06-25 17:28 ` Alan Modra
2005-06-27 11:56 ` Eric Botcazou
2005-06-28 2:58 ` Alan Modra
2005-06-28 7:40 ` Eric Botcazou
2005-06-28 11:42 ` Alan Modra
2005-06-28 11:58 ` Eric Botcazou
2005-06-29 1:24 ` Alan Modra
2005-06-29 6:52 ` Eric Botcazou
2005-06-29 12:45 ` Jonathan Larmour
2005-06-29 13:54 ` Alan Modra
2005-06-29 22:31 ` Jonathan Larmour
2005-06-30 22:28 ` Alan Modra
2005-07-01 13:31 ` Jonathan Larmour
2005-07-04 4:50 ` Alan Modra
2005-07-04 10:55 ` Jonathan Larmour
2005-07-26 11:30 ` Alan Modra
2005-07-26 12:05 ` Alan Modra
2005-08-25 0:06 ` Jim Blandy
2005-08-25 0:48 ` Alan Modra
2005-06-10 13:35 ` Eric Botcazou
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).