Re: linkonce sections, DWARF2 EH, and the ppc failures

[Geoff Keating <geoffk at geoffk dot org>]

"Maciej W. Rozycki" <macro@ds2.pg.gda.pl> writes:

> On Sun, 17 Jun 2001, Geoff Keating wrote:
> 
> > which is IMHO not an unreasonable thing to do.  The linker then
> > combines all the linkonce sections, and decides to resolve this symbol
> > to the start of the linkonce section in the _output_ file.
> 
>  That's an expected behaviour.

That's not how it works for non-linkonce sections.  For those
sections, the section symbol is resolved to the position where the
input section got placed in the output file.

> > Unfortunately, the two compiled procedures differ because the
> > testsuite is compiled with -O0 and string-inst.o is compiled with -O2,
> > so the unwinder loses its mind and aborts.
> 
>  While the actual code may differ, its semantics must be the same for all
> procedures.  Otherwise the whole idea of linkonce sections makes no sense 
> (and your C++ code will break).

Yes, but in this case it has to be identical down to the opcode level
for proper unwinding.  Are we going to require that C++ libraries be
compiled with the same optimisation options as the programs that use them?

> > IMHO, the linker behaviour here is wrong.  The reloc refers to the
> > start of the `.gnu.linkonce.t._ZNKSs2atEj' section in the input file.
> > If that section is not going into the output file, the linker should
> > behave as if that symbol was undefined.
> 
>  Wrong.  Linkonce sections are used for templates.  The idea is to keep a
> single copy of code that gets included in a binary and might be invoked
> from code linked in from different object modules.  I can't check exact
> implementation details now -- I'm away and I don't have gcc sources handy. 
> But check the "Template Instantiation" node in gcc's info pages for more
> information. 

Yes, I know how GCC's templates work under ELF.  However, GCC will
never output an explicit reference to a section symbol.  To refer to
the data in the linkonce section it puts a globally-visible symbol at
the start of the linkonce section and refers to that instead.  This
will still work because all linkonce sections with the same name will
define the symbol.

> > Unfortunately, this doesn't solve my problem, because what I really
> > want is to have the reloc resolved to (say) zero.
> 
>  I don't think this is right -- you want the reloc be resolved to the real
> symbol, not any fake one.

What if the 'real symbol' isn't in the output file?

The specific problem here is code like

	.section ".gnu.linkonce.foo"
	.globl foo
foo:
.L123:	nop
	rts
.L124:

	.rodata
	.word .L123 		; start address
	.word .L124-.L123	; length

in one file, and

	.section ".gnu.linkonce.foo"
	.globl foo
foo:
.L6:	rts
.L7:

	.rodata
	.word .L6		; start address
	.word .L7-.L6		; length

in another.  The linker is using the first copy of the linkonce
section, but the unwinder sees the table from the second file first,
sees that it matches, but gets incorrect information about (for
instance) the length of the procedure.

> > So, how about this?
> 
>  This seems wrong.  You should fix the DWARF2 unwinder, I suppose.

How?  The unwinder is being passed invalid information that is
indistinguishable from correct information.

-- 
- Geoffrey Keating <geoffk@geoffk.org>