gc sections and .eh_frame

[Eric Botcazou]

> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: d106-019_linker-3.diff
Type: text/x-diff
Size: 3311 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20050627/a1b3d7fb/attachment.bin>