[BUG] Regression in 2.14.90 (relative to 2.13.90)
Carlo Wood
carlo@alinoe.com
Thu Nov 13 22:12:00 GMT 2003
On Wed, Nov 12, 2003 at 10:20:17AM -0800, H. J. Lu wrote:
> > The change is intentional. The testcase looks normal to me since
> > the discarded function is identical to the remained. Is there a
> > problem with gdb? Please follow
> >
> > http://sources.redhat.com/ml/binutils/2003-06/msg00471.html
I fail to understand how .eh_frame is related to this .debug_info
problem.
> I took a look at the original bug report:
>
> http://gcc.gnu.org/ml/gcc/2003-10/msg00657.html
>
> The issue here is 2 functions have the same size, but slightly
> different. I don't think we can solve all those link-once debug
> problems without SHT_GROUP.
You cannot assume that functions with the same name, from
different compilation units, are 100% equal; not even if
the same is equal (that can be used as safety-gard, but it
is a very poor one then).
Therefore, if the linker chooses a function from one compilation
unit, it should at all times use the .debug_line info for that
function from the same compilation unit.
Now, the way thinks work - that is not possible yet (without
SHT_GROUP).
But Jason Merrill says
http://gcc.gnu.org/ml/gcc/2003-10/msg00682.html
"I don't see why there would be a problem with the current
situation; only the right .debug_line info should match the current PC."
and in http://gcc.gnu.org/ml/gcc/2003-10/msg00689.html
"... the relocs in the .debug_line info for the discarded copy should
resolve to 0. That's how we deal with duplicate .debug_info ..."
And then he came with the test case
http://gcc.gnu.org/ml/gcc/2003-10/msg00723.html
to show how that works - and it turned out not to work anymore
with binutils-2.14.90.
Is there any reason why this can't be changed back?
--
Carlo Wood <carlo@alinoe.com>
More information about the Binutils
mailing list