"ld" and "QCC" hang trying to link valid object file

bridged with qdn.public.qnxrtp.devtools
John Nagle

"ld" and "QCC" hang trying to link valid object file

Post by John Nagle » Fri Jan 31, 2003 6:50 pm

I have a C++ program which, when compiled, generates
a .o file that hangs the loader.

The program compiles fine, and it was running until
I reorganized some code. Now, "ld" (and QCC) hang when
I try to link it. The loader uses more and more memory until
memory fills, which takes about five seconds.

This is completely repeatable; I can recompile and it
will happen again.

Even just trying

QCC businfo.o

will hang on this file. So will

ld businfo.o

However, "nm businfo.o" creates a reasonable symbol list; the file
is not junk.

Incidentally, "QCC filename.o" will usually generate an a.out
file with no errors when the .o file has no "main"
function. "ld" will complain, but "QCC" will not. So
"QCC" is suppressing some loader error messages.

Is this a known bug?

[QNX 6.20 NC, x86]

John Nagle
Animats

John Nagle

Re: "ld" and "QCC" hang trying to link valid object file

Post by John Nagle » Fri Jan 31, 2003 7:22 pm

Removing some code from the troublesome C++ file
led to a .o file which, when linked, crashes "ld". Here's
the stack from the crashed "ld". Is this a known problem?

John Nagle
Animats

$ gdb /usr/bin/ld --core=ld.core
GNU gdb 5.0 (UI_OUT)
Copyright 2000 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 "--host=x86-pc-nto-qnx --target=ntox86"...
(no debugging symbols found)...
Program terminated with signal 11, segmentation violation.
Reading symbols from /x86/usr/lib/libbfd-2.10.1.so...(no debugging
symbols found)...done.
Reading symbols from /x86/lib/libc.so.2...(no debugging symbols
found)...done.
#0 0xb8216196 in bfd_getl16 () from /x86/usr/lib/libbfd-2.10.1.so
(gdb) backtrace
#0 0xb8216196 in bfd_getl16 () from /x86/usr/lib/libbfd-2.10.1.so
#1 0xb8236a47 in parse_die () from /x86/usr/lib/libbfd-2.10.1.so
#2 0xb8236d53 in parse_functions_in_unit () from
/x86/usr/lib/libbfd-2.10.1.so
#3 0xb8236e2a in dwarf1_unit_find_nearest_line () from
/x86/usr/lib/libbfd-2.10.1.so
#4 0xb823703e in _bfd_dwarf1_find_nearest_line () from
/x86/usr/lib/libbfd-2.10.1.so
#5 0xb8233a29 in _bfd_elf_find_nearest_line () from
/x86/usr/lib/libbfd-2.10.1.so
#6 0x0805b149 in main ()
#7 0x0805b506 in main ()
#8 0x0805833c in main ()
#9 0xb8222316 in elf_i386_relocate_section () from
/x86/usr/lib/libbfd-2.10.1.so
#10 0xb822ba4e in elf_link_input_bfd () from /x86/usr/lib/libbfd-2.10.1.so
#11 0xb822a191 in bfd_elf32_bfd_final_link () from
/x86/usr/lib/libbfd-2.10.1.so
#12 0x08058fa5 in main ()
#13 0x0805688e in main ()
(gdb)

John Nagle wrote:
I have a C++ program which, when compiled, generates
a .o file that hangs the loader.

The program compiles fine, and it was running until
I reorganized some code. Now, "ld" (and QCC) hang when
I try to link it. The loader uses more and more memory until
memory fills, which takes about five seconds.

This is completely repeatable; I can recompile and it
will happen again.

Even just trying

QCC businfo.o

will hang on this file. So will

ld businfo.o

However, "nm businfo.o" creates a reasonable symbol list; the file
is not junk.

Incidentally, "QCC filename.o" will usually generate an a.out
file with no errors when the .o file has no "main"
function. "ld" will complain, but "QCC" will not. So
"QCC" is suppressing some loader error messages.

Is this a known bug?

[QNX 6.20 NC, x86]

John Nagle
Animats

Colin Burgess

Re: "ld" and "QCC" hang trying to link valid object file

Post by Colin Burgess » Fri Jan 31, 2003 7:56 pm

If you try compiling with some other debug format (eg -gstabs+ or -gdwarf-2)
do things get better?

John Nagle <nagle@downside.com> wrote:
Removing some code from the troublesome C++ file
led to a .o file which, when linked, crashes "ld". Here's
the stack from the crashed "ld". Is this a known problem?

John Nagle
Animats

$ gdb /usr/bin/ld --core=ld.core
GNU gdb 5.0 (UI_OUT)
Copyright 2000 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 "--host=x86-pc-nto-qnx --target=ntox86"...
(no debugging symbols found)...
Program terminated with signal 11, segmentation violation.
Reading symbols from /x86/usr/lib/libbfd-2.10.1.so...(no debugging
symbols found)...done.
Reading symbols from /x86/lib/libc.so.2...(no debugging symbols
found)...done.
#0 0xb8216196 in bfd_getl16 () from /x86/usr/lib/libbfd-2.10.1.so
(gdb) backtrace
#0 0xb8216196 in bfd_getl16 () from /x86/usr/lib/libbfd-2.10.1.so
#1 0xb8236a47 in parse_die () from /x86/usr/lib/libbfd-2.10.1.so
#2 0xb8236d53 in parse_functions_in_unit () from
/x86/usr/lib/libbfd-2.10.1.so
#3 0xb8236e2a in dwarf1_unit_find_nearest_line () from
/x86/usr/lib/libbfd-2.10.1.so
#4 0xb823703e in _bfd_dwarf1_find_nearest_line () from
/x86/usr/lib/libbfd-2.10.1.so
#5 0xb8233a29 in _bfd_elf_find_nearest_line () from
/x86/usr/lib/libbfd-2.10.1.so
#6 0x0805b149 in main ()
#7 0x0805b506 in main ()
#8 0x0805833c in main ()
#9 0xb8222316 in elf_i386_relocate_section () from
/x86/usr/lib/libbfd-2.10.1.so
#10 0xb822ba4e in elf_link_input_bfd () from /x86/usr/lib/libbfd-2.10.1.so
#11 0xb822a191 in bfd_elf32_bfd_final_link () from
/x86/usr/lib/libbfd-2.10.1.so
#12 0x08058fa5 in main ()
#13 0x0805688e in main ()
(gdb)

John Nagle wrote:

I have a C++ program which, when compiled, generates
a .o file that hangs the loader.

The program compiles fine, and it was running until
I reorganized some code. Now, "ld" (and QCC) hang when
I try to link it. The loader uses more and more memory until
memory fills, which takes about five seconds.

This is completely repeatable; I can recompile and it
will happen again.

Even just trying

QCC businfo.o

will hang on this file. So will

ld businfo.o

However, "nm businfo.o" creates a reasonable symbol list; the file
is not junk.

Incidentally, "QCC filename.o" will usually generate an a.out
file with no errors when the .o file has no "main"
function. "ld" will complain, but "QCC" will not. So
"QCC" is suppressing some loader error messages.

Is this a known bug?

[QNX 6.20 NC, x86]

John Nagle
Animats

--
cburgess@qnx.com

John Nagle

Re: "ld" and "QCC" hang trying to link valid object file

Post by John Nagle » Fri Jan 31, 2003 9:32 pm

Here's a very small example that breaks the linker.
This is wierd. It looks like QCC is generating bad
output. It does seem to be sensitive to "QCC" vs
"QCC -Vgcc_ntox86".

This is keeping a large program from building,
and it's not clear how to work around it.

John Nagle
Animats

//
//
Small example of program that crashes the linker.
//
Cut down from a larger program.
//
John Nagle / Animats / nagle@animats.com
//
Fails under QNX 6.20 NC (x86)
//
//
Test this with
//
QCC -Vgcc_ntox86 -g -c badfile.cpp
//
ld badfile.o
//
//
"ld" will core dump.
//

//
QCC badfile.o
//
produces no error messages, but makes a bad a.out file.
//
//
Note that "testfn2" is undefined at link time. That somehow
//
causes a crash in the linker.
//
//
Every line in the example below is needed to make this fail.
//
But delete the line with the vector<int> declaration,and
//
the error message from the linker is:
//
//
badfile12.o: In function `__lexicographical_compare_3way':
//
badfile12.cpp:33: undefined reference to `testfn2(void)'
//
//
indicating a bad symbol table generated in QCC.

#include <vector>

class testclass1 {
private:
vector<int> m_devs;
public:
int classfn() const { return(0); }
};

int testfn2();
void testfn1()
{
testfn2();
}

Colin Burgess

Re: "ld" and "QCC" hang trying to link valid object file

Post by Colin Burgess » Fri Jan 31, 2003 9:49 pm

This works fine on my 6.2.1 system. Tools guys? Note that this is NC,
so it's using GNU libstdc++

John Nagle <nagle@downside.com> wrote:
Here's a very small example that breaks the linker.
This is wierd. It looks like QCC is generating bad
output. It does seem to be sensitive to "QCC" vs
"QCC -Vgcc_ntox86".

This is keeping a large program from building,
and it's not clear how to work around it.

John Nagle
Animats

//
//
Small example of program that crashes the linker.
//
Cut down from a larger program.
//
John Nagle / Animats / nagle@animats.com
//
Fails under QNX 6.20 NC (x86)
//
//
Test this with
//
QCC -Vgcc_ntox86 -g -c badfile.cpp
//
ld badfile.o
//
//
"ld" will core dump.
//

//
QCC badfile.o
//
produces no error messages, but makes a bad a.out file.
//
//
Note that "testfn2" is undefined at link time. That somehow
//
causes a crash in the linker.
//
//
Every line in the example below is needed to make this fail.
//
But delete the line with the vector<int> declaration,and
//
the error message from the linker is:
//
//
badfile12.o: In function `__lexicographical_compare_3way':
//
badfile12.cpp:33: undefined reference to `testfn2(void)'
//
//
indicating a bad symbol table generated in QCC.

#include <vector

class testclass1 {
private:
vector<int> m_devs;
public:
int classfn() const { return(0); }
};

int testfn2();
void testfn1()
{
testfn2();
}

--
cburgess@qnx.com

John Nagle

Re: "ld" and "QCC" hang trying to link valid object file

Post by John Nagle » Fri Jan 31, 2003 11:05 pm

It seems to be the combination of an undefined symbol and
the mere declaration of a class with a "vector" that does it.

John Nagle
Animats

Colin Burgess wrote:
This works fine on my 6.2.1 system. Tools guys? Note that this is NC,
so it's using GNU libstdc++

Shouqin Huo

Re: "ld" and "QCC" hang trying to link valid object file

Post by Shouqin Huo » Mon Feb 03, 2003 6:37 pm

We have been having weird problems like this with QCC too. The program would
link without any error messages, but the generated file is not executable.
We have not isolated the problem. But with the combination of reordering
the object files and exclusion of some classes, we managed to get it to
compile correctly. I hope someone can explain it. (The Dinkum C++ libraries
have troubles with STL, we are using the GCC libraries.)

Shouqin Huo

"John Nagle" <nagle@downside.com> wrote in message
news:3E3B0150.90108@downside.com...
It seems to be the combination of an undefined symbol and
the mere declaration of a class with a "vector" that does it.

John Nagle
Animats

Colin Burgess wrote:

This works fine on my 6.2.1 system. Tools guys? Note that this is NC,
so it's using GNU libstdc++

Kris Warkentin

Re: "ld" and "QCC" hang trying to link valid object file

Post by Kris Warkentin » Mon Feb 03, 2003 8:26 pm

"Shouqin Huo" <huo@qm.com> wrote in message news:b1mc21$i31$1@inn.qnx.com...
We have been having weird problems like this with QCC too. The program
would
link without any error messages, but the generated file is not executable.
We have not isolated the problem. But with the combination of reordering
the object files and exclusion of some classes, we managed to get it to
compile correctly. I hope someone can explain it. (The Dinkum C++
libraries
have troubles with STL, we are using the GCC libraries.)
There are certain situations when a stage of compilation fails silently and
qcc doesn't report it. In your case, it's most likely the linker. Try
running qcc with -v (also try -Wl,-v) and you might see what's happening.

cheers,

Kris

John Nagle

Re: "ld" and "QCC" hang trying to link valid object file

Post by John Nagle » Mon Feb 03, 2003 9:23 pm

I get that one too. Small changes to the small program I posted
will yield one of the following behaviors:

- "ld" reports an undefined symbol, but associated
it with a completely irrelevant function.
- QCC, invoking the linker, generates an output file
without the executable bit set. No error messages
are produced. This seems to be a QCC bug.
- "ld" exits with a memory fault. (backtrace posted
previously)
- "ld" loops, acquiring more and more memory until
memory is full, then stalls.

All of this seems to be related to incorrect handling of a link
with undefined symbols.

Running "ld --verbose" doesn't help much. No messages
indicating trouble appear. Even when it's stuck in a loop, the
linker doesn't print anything.

What I suspect is happening is that QSSL's modified
"gcc" is generating a malformed output file, which is
crashing "ld". The developers of GNU "ld" take
the position that no malformed input should ever make it crash.
Is the "ld" shipped with QNX 6.20 NC a stock GNU linker,
or has it been modified?

John Nagle
Animats

Shouqin Huo wrote:
We have been having weird problems like this with QCC too. The program would
link without any error messages, but the generated file is not executable.
We have not isolated the problem. But with the combination of reordering
the object files and exclusion of some classes, we managed to get it to
compile correctly. I hope someone can explain it. (The Dinkum C++ libraries
have troubles with STL, we are using the GCC libraries.)

Shouqin Huo

"John Nagle" <nagle@downside.com> wrote in message
news:3E3B0150.90108@downside.com...

It seems to be the combination of an undefined symbol and
the mere declaration of a class with a "vector" that does it.

John Nagle
Animats

Colin Burgess wrote:


This works fine on my 6.2.1 system. Tools guys? Note that this is NC,
so it's using GNU libstdc++


John Nagle

Re: "ld" and "QCC" hang trying to link valid object file

Post by John Nagle » Tue Feb 04, 2003 6:17 pm

Does QSSL fix this, or should it be reported to the
maintainers of GNU "ld" at the Free Software Foundation?
Should we bring over a later version of "ld" and build it
under QNX? Is the QNX CVS archive for "ld" at

http://cvs.qnx.com/cgi-bin/cvsweb.cgi/t ... nutils/ld/

current? (It doesn't appear to be.)

John Nagle
Animats

John Nagle wrote:
I get that one too. Small changes to the small program I posted
will yield one of the following behaviors:

- "ld" reports an undefined symbol, but associated
it with a completely irrelevant function.
- QCC, invoking the linker, generates an output file
without the executable bit set. No error messages
are produced. This seems to be a QCC bug.
- "ld" exits with a memory fault. (backtrace posted
previously)
- "ld" loops, acquiring more and more memory until
memory is full, then stalls.

All of this seems to be related to incorrect handling of a link
with undefined symbols.

Running "ld --verbose" doesn't help much. No messages
indicating trouble appear. Even when it's stuck in a loop, the
linker doesn't print anything.

What I suspect is happening is that QSSL's modified
"gcc" is generating a malformed output file, which is
crashing "ld". The developers of GNU "ld" take
the position that no malformed input should ever make it crash.
Is the "ld" shipped with QNX 6.20 NC a stock GNU linker,
or has it been modified?

John Nagle
Animats

Shouqin Huo wrote:

We have been having weird problems like this with QCC too. The program
would
link without any error messages, but the generated file is not
executable.
We have not isolated the problem. But with the combination of reordering
the object files and exclusion of some classes, we managed to get it to
compile correctly. I hope someone can explain it. (The Dinkum C++
libraries
have troubles with STL, we are using the GCC libraries.)

Shouqin Huo

"John Nagle" <nagle@downside.com> wrote in message
news:3E3B0150.90108@downside.com...

It seems to be the combination of an undefined symbol and
the mere declaration of a class with a "vector" that does it.

John Nagle
Animats

Colin Burgess wrote:


This works fine on my 6.2.1 system. Tools guys? Note that this is NC,
so it's using GNU libstdc++



John Nagle

Re: "ld" and "QCC" hang trying to link valid object file

Post by John Nagle » Tue Feb 11, 2003 11:18 pm

Any word on this? I'm currently programming by using
"nm" to read out all the undefined symbols and checking
them by hand when the QNX "ld" fails. This is becoming
somewhat annoying.

If it's the Free Software Foundation's problem, let
me know, and I'll bug one of the GNU developers. I'm
still not clear on whether QSSL or FSF maintains the
QNX "ld". Thanks.

John Nagle
Animats

John Nagle wrote:
Does QSSL fix this, or should it be reported to the
maintainers of GNU "ld" at the Free Software Foundation?
Should we bring over a later version of "ld" and build it
under QNX? Is the QNX CVS archive for "ld" at

http://cvs.qnx.com/cgi-bin/cvsweb.cgi/t ... nutils/ld/

current? (It doesn't appear to be.)

John Nagle
Animats

John Nagle wrote:

I get that one too. Small changes to the small program I posted
will yield one of the following behaviors:

- "ld" reports an undefined symbol, but associated
it with a completely irrelevant function.
- QCC, invoking the linker, generates an output file
without the executable bit set. No error messages
are produced. This seems to be a QCC bug.
- "ld" exits with a memory fault. (backtrace posted
previously)
- "ld" loops, acquiring more and more memory until
memory is full, then stalls.

All of this seems to be related to incorrect handling of a link
with undefined symbols.

Running "ld --verbose" doesn't help much. No messages
indicating trouble appear. Even when it's stuck in a loop, the
linker doesn't print anything.

What I suspect is happening is that QSSL's modified
"gcc" is generating a malformed output file, which is
crashing "ld". The developers of GNU "ld" take
the position that no malformed input should ever make it crash.
Is the "ld" shipped with QNX 6.20 NC a stock GNU linker,
or has it been modified?

John Nagle
Animats

Shouqin Huo wrote:

We have been having weird problems like this with QCC too. The
program would
link without any error messages, but the generated file is not
executable.
We have not isolated the problem. But with the combination of
reordering
the object files and exclusion of some classes, we managed to get it to
compile correctly. I hope someone can explain it. (The Dinkum C++
libraries
have troubles with STL, we are using the GCC libraries.)

Shouqin Huo

"John Nagle" <nagle@downside.com> wrote in message
news:3E3B0150.90108@downside.com...

It seems to be the combination of an undefined symbol and
the mere declaration of a class with a "vector" that does it.

John Nagle
Animats

Colin Burgess wrote:


This works fine on my 6.2.1 system. Tools guys? Note that this is
NC,
so it's using GNU libstdc++




Chris McKillop

Re: "ld" and "QCC" hang trying to link valid object file

Post by Chris McKillop » Wed Feb 12, 2003 5:39 am

John Nagle <nagle@downside.com> wrote:
Any word on this? I'm currently programming by using
"nm" to read out all the undefined symbols and checking
them by hand when the QNX "ld" fails. This is becoming
somewhat annoying.

If it's the Free Software Foundation's problem, let
me know, and I'll bug one of the GNU developers. I'm
still not clear on whether QSSL or FSF maintains the
QNX "ld". Thanks.
I just tried your code on a 6.2.0 PE, 6.2.1 PE and 6.2.0 NC. Now, I am
using our recursive build system, you can get the sources here:

http://qnx.wox.org/nagle.tar.gz

In all cases it compiles fine and fails to link. Gives proper warning about
the lack of the missing function. If you get that tarball and run make
does it behave for you?

chris

--
Chris McKillop <cdm@qnx.com> "The faster I go, the behinder I get."
Software Engineer, QSSL -- Lewis Carroll --
http://qnx.wox.org/

John Nagle

Re: "ld" and "QCC" hang trying to link valid object file

Post by John Nagle » Wed Feb 12, 2003 7:00 am

Ah. Unpack that tarball and try

QCC main.cc

and it works fine, producing an error message.

Now try

QCC -g main.cc

to generate debug info. You'll get a junk "a.out" file,
with no error messages. So this problem is somehow
involved with the generation of debug information.

The recursive build system adds quite a few options to
the qcc command line, so it's better to try this with
a cleaner situation.

John Nagle
Animats

Chris McKillop wrote:
John Nagle <nagle@downside.com> wrote:

Any word on this? I'm currently programming by using
"nm" to read out all the undefined symbols and checking
them by hand when the QNX "ld" fails. This is becoming
somewhat annoying.

If it's the Free Software Foundation's problem, let
me know, and I'll bug one of the GNU developers. I'm
still not clear on whether QSSL or FSF maintains the
QNX "ld". Thanks.



I just tried your code on a 6.2.0 PE, 6.2.1 PE and 6.2.0 NC. Now, I am
using our recursive build system, you can get the sources here:

http://qnx.wox.org/nagle.tar.gz

In all cases it compiles fine and fails to link. Gives proper warning about
the lack of the missing function. If you get that tarball and run make
does it behave for you?

chris

Chris McKillop

Re: "ld" and "QCC" hang trying to link valid object file

Post by Chris McKillop » Wed Feb 12, 2003 8:02 am

John Nagle <nagle@downside.com> wrote:
Ah. Unpack that tarball and try

QCC main.cc

and it works fine, producing an error message.

Now try

QCC -g main.cc
Okie dokie - there is a bug in the qcc conf files on 6.2.0 when using
the gcc_ntox86_gpp target (the default for QCC on NC). On a PE machine
under 6.2.0 I can reproduce this bug using:

QCC -Vgcc_ntox86_gpp -g main.cc

However, on 6.2.1 this has been fixed (tested both GNU and Dinkum targets).

This doesn't appear to happen (on 6.2.0) when you use all the options provided
by the recursive make system for a debug target. You can try that out by
invoking "addvariant x86 o.g" and running make in x86/o.g.


chris

--
Chris McKillop <cdm@qnx.com> "The faster I go, the behinder I get."
Software Engineer, QSSL -- Lewis Carroll --
http://qnx.wox.org/

Gerhard Wesp

Re: "ld" and "QCC" hang trying to link valid object file

Post by Gerhard Wesp » Wed Feb 12, 2003 9:11 am

John Nagle <nagle@downside.com> wrote:
If it's the Free Software Foundation's problem, let
me know, and I'll bug one of the GNU developers. I'm
They may not be interested in fixing versions 3 1/2 years of age.

-Gerhard
--
| voice: +43 (0)676 6253725 *** web: http://www.cosy.sbg.ac.at/~gwesp/
|
| Passts auf, seid's vuasichdig, und lossds eich nix gfoin!
| -- Dr. Kurt Ostbahn

Post Reply

Return to “qdn.public.qnxrtp.devtools”