Re: collect2, weak functions and .debug_line section.

[Jason Merrill <jason at redhat dot com>]

On Thu, 16 Oct 2003 15:47:01 -0400, Jason Merrill <jason@redhat.com> wrote:

> On Thu, 16 Oct 2003 15:34:27 -0400, Daniel Jacobowitz <drow@mvista.com> wrote:
>
>> On Thu, Oct 16, 2003 at 03:00:58PM -0400, Jason Merrill wrote:
>
>>> Yes.  But 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.
>>
>> I believe the problem is not with inlining, but with one copy being
>> discarded?
>
> Yes, but the relocs in the .debug_line info for the discarded copy should
> resolve to 0.  That's how we deal with duplicate .debug_info, IIRC.

Here's a testcase that demonstrates this.  In this testcase we get a copy
of f<int> from both wa.C and wa2.C.  The line number info from the
discarded copy in wa2.C properly points into SEGV-land:

$ g++ -g wa.C wa2.C
$ readelf -wl a.out
...
 Line Number Statements:
  Set File Name to entry 2 in the File Name Table
  Extended opcode 2: set Address to 0x0
  Special opcode 9: advance Address by 0 to 0x0 and Line by 4 to 5
  Special opcode 90: advance Address by 6 to 0x6 and Line by 1 to 6
  Advance PC by 14 to 14
  Extended opcode 1: End of Sequence
...

Carlo, do you get a different result for this testcase?

Attachment: line.tar.gz
Description: GNU Zip compressed data