This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |