public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
From: miwako.tokugawa@intel.com
To: gcc-gnats@gcc.gnu.org
Cc: SvetlanaX_Gvozdeva@vniief.ims.intel.com
Subject: other/7671: RH7.3 gnu ld (version 2.11.93.0.2 20020207) problem w/ gnu.linkonce.*
Date: Tue, 20 Aug 2002 20:06:00 -0000	[thread overview]
Message-ID: <20020821010705.19457.qmail@sources.redhat.com> (raw)


>Number:         7671
>Category:       other
>Synopsis:       RH7.3 gnu ld (version 2.11.93.0.2 20020207) problem w/ gnu.linkonce.*
>Confidential:   no
>Severity:       critical
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Aug 20 18:16:00 PDT 2002
>Closed-Date:
>Last-Modified:
>Originator:     miwako.tokugawa@intel.com
>Release:        unknown-1.0
>Organization:
>Environment:

>Description:
ld on RH7.3 (2.11.93.0.2. 20020207) seems to have a problem with .gnu.linknce.t<...> (and possibly .d, .w..) This is a regression from older versions. 

Given 
file1: .textfile1 + gnu.linkonce.t1+...gnu.linkonce.tn
file2: .textfile2 + gnu.linkonce.t12+...gnu.linkonce.tn2
.....
filen: .textfilen + gnu.linkonce.t13+...gnu.linkonce.tn3

Older linkers combine sections with code in .text section in the following order:
executable file: textfile1+ textfile2 + ... + textfilen + gnu.linkonce.t1+...gnu.linkonce.tn3

while the new linker does:
executable file: textfile1 + gnu.linkonce.t1+...gnu.linkonce.tn + textfile2 + gnu.linkonce.t12+...gnu.linkonce.tn2 + ... +
textfilen + gnu.linkonce.t13+...gnu.linkonce.tn3.

If we compile files with debug information then every object file has sections .debug_info, .debug_line and rel.debug_info and .rel_debug_line.
Some records for relocation refer to start of sections .gnu.linkonce.t<..>.
If some object files have the same sections .gnu.linkonce.t<...> then they may have the records of relocations, which refer to the start of the same .gnu.linkonce.t<...> sections. 

The new linker is able to resolve records for relocations that refer to the start of the same .gnu.linkonce.t.<..> sections correctly for the first processed object file ONLY!!! The relocation records in other object files that refer to the same .gnu.linkonce.t<..> section are not resolved at all!

If you build test ladbCpp/test01a using command line as 'g++ -gdwarf-2 test01a.cpp test01b.cpp test01c.cpp'  on Red Hat 7.3 you can make dump of debug information and see (fragment of debug information about line numbers):

Extended opcode 2: set Address to 0x0
  Set File Name to entry 2 in the File Name Table
  Special opcode 13: advance Address by 0 to 0x0 and Line by 3 to 4
  Extended opcode 2: set Address to 0x15
  Extended opcode 1: End of Sequence

  Extended opcode 2: set Address to 0x0
  Set File Name to entry 3 in the File Name Table
  Special opcode 13: advance Address by 0 to 0x0 and Line by 3 to 4
  Extended opcode 2: set Address to 0x15
  Extended opcode 1: End of Sequence

I have attached the dump as dump.txt

Example of test debug session with GDB for test01a, which was built by 'g++' for Red Hat 7.3:

[sana@altair opt_debug_asm]$ gdb g++.out
GNU gdb Red Hat Linux (5.1.90CVS-5)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux"...
(gdb) b foo2
Breakpoint 1 at 0x8048702: file test01c.cpp, line 6.
(gdb) r
Starting program: /home/sana/iidb/idbCpp/opt_debug_asm/g++.out 

Breakpoint 1, foo2 (a=1) at test01c.cpp:6
6       A *pa = new A;
(gdb) b test01a.h:4
Note: breakpoint -12 (disabled) also set at pc 0x0.
Breakpoint 2 at 0x0: file test01a.h, line 4.
(gdb) 

The same test debug session for Red Hat 7.1:

GNU gdb 5.0rh-5 Red Hat Linux 7.1
Copyright 2001 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux"...
(gdb) b foo2
Breakpoint 1 at 0x8048736: file test01c.cpp, line 6.
(gdb) r
Starting program: /home1/sana/miwako_opyt/a.out 

Breakpoint 1, foo2 (a=1) at test01c.cpp:6
6       A *pa = new A;
Current language:  auto; currently c++
(gdb) b test01a.h:4
Breakpoint 2 at 0x8048860: file test01a.h, line 4.
(gdb)
>How-To-Repeat:
Please see Description and 28302.zip/command.txt
>Fix:

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


             reply	other threads:[~2002-08-21  1:16 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-08-20 20:06 miwako.tokugawa [this message]
2003-05-13 18:26 Dara Hazeghi
2003-05-14 10:28 giovannibajo

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=20020821010705.19457.qmail@sources.redhat.com \
    --to=miwako.tokugawa@intel.com \
    --cc=SvetlanaX_Gvozdeva@vniief.ims.intel.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).