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

QNX Newsgroups (Archives) qdn.public.qnxrtp.devtools
1

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

2

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

3

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

4

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 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

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

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

5

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 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 m_devs;
public:
int classfn() const { return(0); }
};

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

–
cburgess@qnx.com

6

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++

7

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++

8

“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

9

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++

10

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/tools/binutils/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++
\

11

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/tools/binutils/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++

\

12

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/

13

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

14

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/

15

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

16

Thanks. This is very significant information for me. By turning off the
debug flag, I was able to quickly resolve the problem that has been bugging
me for weeks.

I have had the debug flag on before. Without any error messages, I had to
do binary search to find the class that was causing the problem. I got the
code to compile by excluding one class, but still did not know why. Now with
the debug flag off, I found that there was one undefined function in it. I
fixed it and it compiles happily with or without the debug flag.

Does anyone from QSSL want to comment on this? When can we expect a fix to
the problem?

Shouqin Huo
Quantum Magnetics
“John Nagle” <nagle@downside.com> wrote in message
news:3E49F10E.7090503@downside.com…

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

17

Does anyone from QSSL want to comment on this? When can we expect a fix to
the problem?

I think I already did. :wink:

chris

\

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

18

Between 6.2.0 and 6.2.1 the default debug format changed from Dwarf to Stabs+,
although this suceeds for me on 6.2.1 with -gdwarf.

I do remember fixing an ld bug wrt dwarf1 undefined references a LONG time
ago though, it should have been in 6.2.0

In any case, I’d recommend -gstabs+ to any C++ developers using 6.2.0 - it’s
simply a lot better for C++ than DWARF1.

Chris McKillop <cdm@qnx.com> wrote:

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/

–
cburgess@qnx.com

19

OK, tried that. The “recursive build system” then
introduced a call to “usemsg”, which complained
“Bad format for load module” when processing the .o
file generated with -g enabled. See below. That’s
another indication that compiling with -g is producing
bad .o files.

Adding the options introduced by the “recursive build system”
does not seem to affect the problem. It’s the presence or
absence of “-g” that does it.

Is there some way to get debug info without bad object files?
If this is fixed in 6.2.1, is there a downloadable upgrade
for the NC version?

John Nagle
Animats

$ addvariant x86 o.g
Creating /home/public/nagle/x86/o.g directory…
$ make
make -j 1 -Cx86 -fMakefile
make[1]: Entering directory /home/public/nagle/x86' make -j 1 -Co -fMakefile && make -j 1 -Co.g -fMakefile make[2]: Entering directory /home/public/nagle/x86/o’
make[2]: Nothing to be done for first'. make[2]: Leaving directory /home/public/nagle/x86/o’
make[2]: Entering directory /home/public/nagle/x86/o.g' /usr/bin/qcc -Vgcc_ntox86 -c -Wc,-Wall -Wc,-Wno-parentheses -O -I. -I/home/public/nagle/x86/o -I/home/public/nagle/x86/o.g -I/home/public/nagle/x86 -I/home/public/nagle -I/usr/include -g -DVARIANT_g /home/public/nagle/main.cc /bin/rm -f /home/public/nagle/x86/o.g/nagle_g /usr/bin/qcc -Vgcc_ntox86 -lang-c++ -o/home/public/nagle/x86/o.g/nagle_g main.o -L. -L/x86/lib -L/x86/usr/lib -g /usr/bin/usemsg -s __USAGENTO -s __USAGE /home/public/nagle/x86/o.g/nagle_g /home/public/nagle/nagle.use Bad format for load module /home/public/nagle/x86/o.g/nagle_g. make[2]: *** [/home/public/nagle/x86/o.g/nagle_g] Error 1 make[2]: Leaving directory /home/public/nagle/x86/o.g’
make[1]: *** [all] Error 2
make[1]: Leaving directory `/home/public/nagle/x86’
make: *** [all] Error 2

Chris McKillop wrote:

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 wrote:

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

20

There was a bug fixed in dwarf1 handling between 6.2.0 and 6.2.1, however
I think that in this case it might not be that one.

I think that nagle_g in this case is probably a corrupt file, and that
ld is crashing somehow. What does file nagle_g say?

Did you try the -gstabs+?

John Nagle <nagle@downside.com> wrote:

OK, tried that. The “recursive build system” then
introduced a call to “usemsg”, which complained
“Bad format for load module” when processing the .o
file generated with -g enabled. See below. That’s
another indication that compiling with -g is producing
bad .o files.

Adding the options introduced by the “recursive build system”
does not seem to affect the problem. It’s the presence or
absence of “-g” that does it.

Is there some way to get debug info without bad object files?
If this is fixed in 6.2.1, is there a downloadable upgrade
for the NC version?

John Nagle
Animats

$ addvariant x86 o.g
Creating /home/public/nagle/x86/o.g directory…
$ make
make -j 1 -Cx86 -fMakefile
make[1]: Entering directory /home/public/nagle/x86' make -j 1 -Co -fMakefile && make -j 1 -Co.g -fMakefile make[2]: Entering directory /home/public/nagle/x86/o’
make[2]: Nothing to be done for first'. make[2]: Leaving directory /home/public/nagle/x86/o’
make[2]: Entering directory /home/public/nagle/x86/o.g' /usr/bin/qcc -Vgcc_ntox86 -c -Wc,-Wall -Wc,-Wno-parentheses -O -I. -I/home/public/nagle/x86/o -I/home/public/nagle/x86/o.g -I/home/public/nagle/x86 -I/home/public/nagle -I/usr/include -g -DVARIANT_g /home/public/nagle/main.cc /bin/rm -f /home/public/nagle/x86/o.g/nagle_g /usr/bin/qcc -Vgcc_ntox86 -lang-c++ -o/home/public/nagle/x86/o.g/nagle_g main.o -L. -L/x86/lib -L/x86/usr/lib -g /usr/bin/usemsg -s __USAGENTO -s __USAGE /home/public/nagle/x86/o.g/nagle_g /home/public/nagle/nagle.use Bad format for load module /home/public/nagle/x86/o.g/nagle_g. make[2]: *** [/home/public/nagle/x86/o.g/nagle_g] Error 1 make[2]: Leaving directory /home/public/nagle/x86/o.g’
make[1]: *** [all] Error 2
make[1]: Leaving directory `/home/public/nagle/x86’
make: *** [all] Error 2

Chris McKillop wrote:
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 wrote:
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

–
cburgess@qnx.com