collect2, weak functions and .debug_line section.

collect2, weak functions and .debug_line section.

[Carlo Wood]

There is a problem with debug information being used
from one object file and the assembly code from another
object file (both containing the "same" function)
that do not completely match, with screwed debug
info as a result.

For example, in mainline, libstdc++.so.6 contains
the code from .libs/demangle.o 's
_ZStplIcSt11char_traitsIcESaIcEESbIT_T0_T1_EPKS3_RKS6_
function, but the .debug_line section info for
that function from the one found in .libs/string-inst.o

If we disassemble both functions then we see that
they are different - and as such, you cannot use
the debug_line info from one and the code from the
other.

--- string-inst.out     2003-10-16 17:49:34.334596248 +0200
+++ demangle.out        2003-10-16 17:48:49.136467408 +0200
@@ -25,12 +25,12 @@
   42:  89 44 24 04             mov    %eax,0x4(%esp,1)
   46:  e8 fc ff ff ff          call   47 <_ZStplIcSt11char_traitsIcESaIcEESbIT_T0_T1_EPKS3_RKS6_+0x47>
   4b:  8b 06                   mov    (%esi),%eax
-  4d:  8b 55 0c                mov    0xc(%ebp),%edx
-  50:  8b 40 f4                mov    0xfffffff4(%eax),%eax
-  53:  89 54 24 0c             mov    %edx,0xc(%esp,1)
-  57:  31 d2                   xor    %edx,%edx
-  59:  89 7c 24 10             mov    %edi,0x10(%esp,1)
-  5d:  89 54 24 08             mov    %edx,0x8(%esp,1)
+  4d:  31 c9                   xor    %ecx,%ecx
+  4f:  8b 55 0c                mov    0xc(%ebp),%edx
+  52:  8b 40 f4                mov    0xfffffff4(%eax),%eax
+  55:  89 7c 24 10             mov    %edi,0x10(%esp,1)
+  59:  89 54 24 0c             mov    %edx,0xc(%esp,1)
+  5d:  89 4c 24 08             mov    %ecx,0x8(%esp,1)
   61:  89 44 24 04             mov    %eax,0x4(%esp,1)
   65:  89 34 24                mov    %esi,(%esp,1)
   68:  e8 fc ff ff ff          call   69 <_ZStplIcSt11char_traitsIcESaIcEESbIT_T0_T1_EPKS3_RKS6_+0x69>

I am not sure how to report this in GNATS.
What component would this belong to?
Heh - I don't even know which mailinglist this belongs to :/

Does anyone have ideas of how to fix this?

-- 
Carlo Wood <carlo@alinoe.com>

Re: collect2, weak functions and .debug_line section.

[Daniel Jacobowitz]

On Thu, Oct 16, 2003 at 05:55:24PM +0200, Carlo Wood wrote:
> There is a problem with debug information being used
> from one object file and the assembly code from another
> object file (both containing the "same" function)
> that do not completely match, with screwed debug
> info as a result.

> I am not sure how to report this in GNATS.
> What component would this belong to?
> Heh - I don't even know which mailinglist this belongs to :/
> 
> Does anyone have ideas of how to fix this?

Search the archives for more.  I believe that the proper fix is to use
ELF section groups, but I don't know much about the details.  One of
the bodies should be discarded, and its debug info should be discarded
als.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: collect2, weak functions and .debug_line section.

[Matt Austern]

On Thursday, October 16, 2003, at 08:58  AM, Daniel Jacobowitz wrote:

> On Thu, Oct 16, 2003 at 05:55:24PM +0200, Carlo Wood wrote:
>> There is a problem with debug information being used
>> from one object file and the assembly code from another
>> object file (both containing the "same" function)
>> that do not completely match, with screwed debug
>> info as a result.
>
>> I am not sure how to report this in GNATS.
>> What component would this belong to?
>> Heh - I don't even know which mailinglist this belongs to :/
>>
>> Does anyone have ideas of how to fix this?
>
> Search the archives for more.  I believe that the proper fix is to use
> ELF section groups, but I don't know much about the details.  One of
> the bodies should be discarded, and its debug info should be discarded
> als.

I plan to start working on SHT_GROUP COMDAT once I'm done with my
current work of enabling vague linkage for Darwin.

Unfortunately, group COMDAT may require some changes in binutils.
It has been implemented in binutils but, without compiler support,
it hasn't really been tested.  There may be some corner cases
that it doesn't quite get right.

			--Matt

SHT_GROUP COMDAT

[H. J. Lu]

On Thu, Oct 16, 2003 at 09:22:27AM -0700, Matt Austern wrote:
> 
> I plan to start working on SHT_GROUP COMDAT once I'm done with my
> current work of enabling vague linkage for Darwin.
> 
> Unfortunately, group COMDAT may require some changes in binutils.
> It has been implemented in binutils but, without compiler support,
> it hasn't really been tested.  There may be some corner cases
> that it doesn't quite get right.

Support multiple sections of the same name with section group is on
my todo list:

http://sources.redhat.com/ml/binutils/2003-06/msg00295.html


H.J.

Re: collect2, weak functions and .debug_line section.

[Carlo Wood]

On Thu, Oct 16, 2003 at 09:22:27AM -0700, Matt Austern wrote:
> I plan to start working on SHT_GROUP COMDAT once I'm done with my
> current work of enabling vague linkage for Darwin.
> 
> Unfortunately, group COMDAT may require some changes in binutils.
> It has been implemented in binutils but, without compiler support,
> it hasn't really been tested.  There may be some corner cases
> that it doesn't quite get right.
> 
> 			--Matt

This is too difficult for me.  I won't be able to look into it,
but I'd still like it to be fixed in the future.  So, where can
I add a PR for this?

-- 
Carlo Wood <carlo@alinoe.com>

Re: collect2, weak functions and .debug_line section.

[Jason Merrill]

On Thu, 16 Oct 2003 11:58:14 -0400, Daniel Jacobowitz <drow@mvista.com> wrote:

> On Thu, Oct 16, 2003 at 05:55:24PM +0200, Carlo Wood wrote:
>> There is a problem with debug information being used
>> from one object file and the assembly code from another
>> object file (both containing the "same" function)
>> that do not completely match, with screwed debug
>> info as a result.
>
>> I am not sure how to report this in GNATS.
>> What component would this belong to?
>> Heh - I don't even know which mailinglist this belongs to :/
>> 
>> Does anyone have ideas of how to fix this?
>
> Search the archives for more.  I believe that the proper fix is to use
> ELF section groups, but I don't know much about the details.  One of
> the bodies should be discarded, and its debug info should be discarded
> also.

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.

Jason

Re: collect2, weak functions and .debug_line section.

[Daniel Jacobowitz]

On Thu, Oct 16, 2003 at 03:00:58PM -0400, Jason Merrill wrote:
> On Thu, 16 Oct 2003 11:58:14 -0400, Daniel Jacobowitz <drow@mvista.com> wrote:
> 
> > On Thu, Oct 16, 2003 at 05:55:24PM +0200, Carlo Wood wrote:
> >> There is a problem with debug information being used
> >> from one object file and the assembly code from another
> >> object file (both containing the "same" function)
> >> that do not completely match, with screwed debug
> >> info as a result.
> >
> >> I am not sure how to report this in GNATS.
> >> What component would this belong to?
> >> Heh - I don't even know which mailinglist this belongs to :/
> >> 
> >> Does anyone have ideas of how to fix this?
> >
> > Search the archives for more.  I believe that the proper fix is to use
> > ELF section groups, but I don't know much about the details.  One of
> > the bodies should be discarded, and its debug info should be discarded
> > also.
> 
> 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?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: collect2, weak functions and .debug_line section.

[Jason Merrill]

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.

Jason

Re: SHT_GROUP COMDAT

[Carlo Wood]

On Thu, Oct 16, 2003 at 09:36:25AM -0700, H. J. Lu wrote:
> On Thu, Oct 16, 2003 at 09:22:27AM -0700, Matt Austern wrote:
> > I plan to start working on SHT_GROUP COMDAT once I'm done with my
> > current work of enabling vague linkage for Darwin.
> > 
> > Unfortunately, group COMDAT may require some changes in binutils.
> > It has been implemented in binutils but, without compiler support,
> > it hasn't really been tested.  There may be some corner cases
> > that it doesn't quite get right.
> 
> Support multiple sections of the same name with section group is on
> my todo list:
> 
> http://sources.redhat.com/ml/binutils/2003-06/msg00295.html

So, there is no support for it in binutils yet?
H.J., the reason that I am interested in this subject is
because certain .gnu.linkonce* sections from different
compile units but containing the same template function
(or call method) instantiation, have each their own line
information being generated and put in the .debug_line
section (from ".loc ..." line in the .s file) by GNU as.
But the assembly code, and therefore the line number information
of these two instantiations can slightly differ.  GNU ld now
picks one instantiation, and an arbitrary .debug_line
part covering the function  - sometimes not the matching
one.

Therefore, one of the things that is needed is that 'GNU as'
needs to generate section groups for the .debug_line sections,
of .gnu.linkonce* "instantiations", linking the ones that belong
together.

Sorry if I am being unclear - it is not clear to myself
how this should be solved.  But it seem specific enough
to need special attention;  I was wondering if this will
be on your todo list too :).

-- 
Carlo Wood <carlo@alinoe.com>

Re: collect2, weak functions and .debug_line section.

[Jason Merrill]

[-- Attachment #1: Type: text/plain, Size: 1229 bytes --]

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 #2: line.tar.gz --]
[-- Type: application/x-gzip, Size: 304 bytes --]

Re: collect2, weak functions and .debug_line section.

[Carlo Wood]

On Fri, Oct 17, 2003 at 10:19:07AM -0400, Jason Merrill wrote:
> Carlo, do you get a different result for this testcase?

This thread has been moved to the binutils@ mailinglist.

My reply is here:

http://sources.redhat.com/ml/binutils/2003-10/msg00456.html

-- 
Carlo Wood <carlo@alinoe.com>