First Last Prev Next    No search results available      Search page      Enter new bug
Bug#: 7671
Product:  
Component:  
Status: RESOLVED
Resolution: INVALID
Assigned To: Not yet assigned to anyone <unassigned@gcc.gnu.org>
Host:
Reported against  
Priority:  
Severity:  
Target Milestone:  
 
 
Target:
Reporter: miwako.tokugawa@intel.com
Add CC:
CC:
Remove selected CCs
Build:
URL:
Summary:
Keywords:
Known to work:
Known to fail:

Attachment Description Type Created Size Actions
Create a New Attachment (proposed patch, testcase, etc.) View All

Bug 7671 depends on: Show dependency tree
Show dependency graph
Bug 7671 blocks:

Additional Comments:






View Bug Activity   |   Format For Printing   |   Clone This Bug


Description:   Last confirmed: Opened: 2002-08-20 18:16
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)

Release:
unknown

How-To-Repeat:
Please see Description and 28302.zip/command.txt

------- Comment #1 From Dara Hazeghi 2003-05-13 11:18 -------
From: Dara Hazeghi <dhazeghi@yahoo.com>
To: SvetlanaX_Gvozdeva@vniief.ims.intel.com, miwako.tokugawa@intel.com,
   gcc-gnats@gcc.gnu.org, nobody@gcc.gnu.org
Cc:  
Subject: Re: other/7671: RH7.3 gnu ld (version 2.11.93.0.2 20020207) problem w/ gnu.linkonce.*
Date: Tue, 13 May 2003 11:18:31 -0700

 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit- 
 trail&database=gcc&pr=7671
 
 Hello,
 
 firstly this bug report appears to be a problem with an unreleased  
 version of ld that RedHat included in their 7.1 distribution. If there  
 is a problem with it, they would be the people to contact, not us.  
 Secondly, ld is not a part of gcc, but of binutils, and a regression of  
 ld should be reported to the binutils list. Finally, your message  
 refers to a nonexistent archive that demonstrates the bug. Could the  
 submitter of this report explain why this bug is a gcc bug, and include  
 a testcase? Otherwise this report will be closed. Thank you,
 
 Dara
 

------- Comment #2 From Giovanni Bajo 2003-05-14 10:28 -------
State-Changed-From-To: open->feedback
State-Changed-Why: See Dara's question

------- Comment #3 From Dara Hazeghi 2003-06-20 21:55 -------
A reminder that this bug is awaiting feedback still. You don't include a
testcase, say what version 
of gcc you're using or explain why this is a gcc, not an ld, bug. Can you
please answer these 
questions. Thanks you.

------- Comment #4 From Andrew Pinski 2003-07-19 18:50 -------
Also starting with gcc 3.3, a binutils of 2.13.1 is required as older version
have bugs 
which make gcc looks like creating wrong-code.
Can you try with both a newer gcc and a new binutils?
Also explain why you think this is a gcc bug rather than a binutils one?

------- Comment #5 From miwako.tokugawa@intel.com 2003-07-19 18:50 -------
Subject: Out of Office AutoReply:  RH7.3 gnu ld (version 2.11.93.0.2 20020207)
problem w/ gnu.linkonce.*

I will be OOO 7/13-21. Will be checking email.

------- Comment #6 From Andrew Pinski 2003-08-11 17:45 -------
No feedback in 3months (really T-2 days) and this looks like a binutils bug and
not a 
GCC one, also 2.11.93.0.2 is an old version of binutils, a non released one
too.

First Last Prev Next    No search results available      Search page      Enter new bug