[BUG] Regression in 2.14.90 (relative to 2.13.90)

[Carlo Wood]

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>