public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
From: carlo@alinoe.com
To: gcc-gnats@gcc.gnu.org
Subject: debug/9509: Incorrect function starts in DWARF2 .debug_line section
Date: Thu, 30 Jan 2003 17:16:00 -0000	[thread overview]
Message-ID: <20030130171302.3363.qmail@sources.redhat.com> (raw)


>Number:         9509
>Category:       debug
>Synopsis:       Incorrect function starts in DWARF2 .debug_line section
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Jan 30 17:16:01 UTC 2003
>Closed-Date:
>Last-Modified:
>Originator:     Carlo Wood
>Release:        3.2.1
>Organization:
>Environment:

>Description:
The match between (sourcefile-) line numbers and the actual
start of functions is (very) often wrong.  This can be
checked with objdump for example.

Using libstdc++ as included with the gcc package as example
(because thats where I first noticed it), issuing for example:

objdump -d -l -j .text /usr/lib/libstdc++.so.5.0.2

shows all function starts and their first line number.

Correct is for example:

0004ab3c <_ZNSt9basic_iosIwSt11char_traitsIwEE4initEPSt15basic_streambufIwS1_E>:
_ZNSt9basic_iosIwSt11char_traitsIwEE4initEPSt15basic_streambufIwS1_E():
/usr/src/redhat/BUILD/gcc-3.2.1-20021208/obj-i386-redhat-linux/i386-redhat-linux/libstdc++-v3/include/bits/basic_ios.tcc:141
   4ab3c:       55                      push   %ebp
   4ab3d:       57                      push   %edi
   4ab3e:       56                      push   %esi

where the sourcefile/line-number immedeately follows the
function header.

However, often we see:

00058078 <_ZNKSt9money_putIcSt19ostreambuf_iteratorIcSt11char_traitsIcEEE6do_putES3_bRSt8ios_basecRKSs>:
_ZNKSt9money_putIcSt19ostreambuf_iteratorIcSt11char_traitsIcEEE6do_putES3_bRSt8ios_basecRKSs():
   58078:       55                      push   %ebp
   58079:       89 e5                   mov    %esp,%ebp
/usr/src/redhat/BUILD/gcc-3.2.1-20021208/obj-i386-redhat-linux/i386-redhat-linux/libstdc++-v3/include/bits/locale_facets.tcc:1205
   5807b:       57                      push   %edi
   5807c:       56                      push   %esi

Where an arbitrary amount of instructions at the start
of the function is skipped.

I found that the reason for this is an incorrect
DW_LNS_advance_pc in the DWARF2 line info of the
*previous* function, just prior to its DW_LNE_end_sequence.
As a result, objdump prints out the above.  The real
problem is that the address of the previous function
is pushed inside and behond the start of the next function:
an incorrect value of DW_LNS_advance_pc thus.

I can only show the analysis output of libcwd (my project)
while it tries to decode the .debug_line section in such
a case to make it a little more clear (hopefully).
For example, the start of the above function is decoded
(correctly) as:

BFD     : |--> location.M_line = 1
BFD     : |DW_LNS_set_file: "/i386-redhat-linux/libstdc++-v3/include/bits/locale_facets.tcc"
BFD     : |--> location invalidated.
BFD     : |DW_LNE_set_address: 0x58078
BFD     : |--> location.M_address = 0x58078
BFD     : |DW_LNS_advance_line: 1204
BFD     : |--> location invalidated.
BFD     : |--> location.M_line = 1205
BFD     : |DW_LNS_copy
BFD     : |--> location assumed valid.
BFD     : |M_store(): M_range.start was 0.
BFD     : |DW_LNS_set_file: "/i386-redhat-linux/libstdc++-v3/include/bits/ios_base.h"
BFD     : |--> location invalidated.
BFD     : |DW_LNS_advance_line: -812
BFD     : |--> location invalidated.
BFD     : |--> location.M_line = 393
BFD     : |DW_LNS_const_add_pc
BFD     : |--> location.M_address = 0x58089
BFD     : |--> location now valid.
BFD     : |M_store(): Registering new range.
BFD     : |58078 - 58089; /i386-redhat-linux/libstdc++-v3/include/bits/locale_facets.tcc:1205 : "-DWARF symbol"..

And found to start at 58078 as per direct setting of
the address (with DW_LNE_set_address).

While the END of the *previous* function gives the
following output:

BFD     : |M_store(): Registering new range.
BFD     : |58064 - 5806e; /i386-redhat-linux/libstdc++-v3/include/bits/locale_facets.tcc:2129 : "-DWARF symbol"..
BFD     : |DW_LNS_advance_pc: c
BFD     : |--> location.M_address = 0x5807a
BFD     : |Skipping M_store: location didn't change.
BFD     : |DW_LNE_end_sequence: Address: 0x5807a
BFD     : |--> Sequence end.
BFD     : |M_store(): Registering new range.
BFD     : |5806e - 5807a; /i386-redhat-linux/libstdc++-v3/include/bits/locale_facets.tcc:2131 : "-DWARF symbol"..
BFD     : |WARNING: Different start for same function (58078 - 58089; /i386-redhat-linux/libstdc++-v3/include/bits/locale_fac
ets.tcc:1205 : "-DWARF symbol"..)!?
BFD     : |WARNING: Different sizes for same function.  Not sure what .stabs entry to use.
BFD     : |WARNING: Different line numbers for overlapping range (58078 - 58089; /i386-redhat-linux/libstdc++-v3/include/bits/locale_facets.tcc:1205 : "-DWARF symbol"..)!?

The problem here is that 5807a, as is the result from the
"DW_LNS_advance_pc: c", is an address way behond the end
of the current function.
>How-To-Repeat:

>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted:


                 reply	other threads:[~2003-01-30 17:16 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20030130171302.3363.qmail@sources.redhat.com \
    --to=carlo@alinoe.com \
    --cc=gcc-gnats@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).