Re: gold vs libc

[Roland McGrath <roland at hack dot frob dot com>]

> I don't fully understand this, but it seems to me that gold's
> behaviour is correct and GNU ld's behaviour is incorrect.  GNU ld is
> effectively discarding the exception frame information in crt1.o, and
> gold is retaining it.

That is neither true nor relevant.  I did not lodge any complaint
about what contents wind up in the .eh_frame output section.  The
problem is how it's treating a symbol defined in an input section.

GNU ld produces an __EH_FRAME_BEGIN__ symbol that points to the place
in the output .eh_frame section that corresponds to the order of input
files' .eh_frame sections.  This does indeed point past the crt1.o
CFI, but that is correct given the input file order (crt1.o and its
.eh_frame content before crtbeginT.o and its __EH_FRAME_BEGIN__
symbol).

Gold produces an __EH_FRAME_BEGIN__ symbol that points to the end of
the .eh_frame output section.  The effect of this is that gold is
"effectively discarding" the entirety of the CFI.  There is no logic
of input sections and symbols and their order by which this result
makes any kind of sense.

The fact that it's CFI data is secondary IMHO.  If the linker wants to
optimize CFI data, then that's a fine thing.  But its starting mandate
has to be that it doesn't break the general rules of how link order
and symbol values would come out if it were any other random rodata
section rather than .eh_frame.

> To put it another way: what principle should gold follow to get the
> result you want?

When an input file contains a symbol pointing to a location in an
input section, the output file should define that symbol so it points
to the part of the output section that corresponds to the origin input
location.  When the symbol points to input contents of at least one
byte, what this means is pretty incontrovertibly clear.  In this case,
it points to an empty input section.  But I claim that it's adequately
clear what it should mean in this case too.


Thanks,
Roland