Re: ld dumping core on large objects when there are unresolved refs

[Kris Warkentin]

Following up to myself, just in case anyone's paying attention ;-)  I chased
the bug down to the dwarf 1 debug info interpretation section in libbfd.
Looks like ld found a problem, tried to be smart and look up stuff in the
debug info and blew up.  Our default debug setting in gcc was dwarf 1 (now
it's stabs+) which isn't particularily useful for C++ anyway.  Just for
curiosity I grabbed a c++ project from the web (aime - c++ mud) and tried to
compile on a Linux box using dwarf debugging and couldn't even get past the
compile stage, never mind the linking.  A bunch of objects came out
correctly but then we got an internal error from bfd_emit_dwarf (or some
such) on one of them.

So, the moral of the story is, "don't use dwarf debugging with c++". (unless
some brave soul wants to dive into libbfd and see why it's having problems
with c++/dwarf ;-)

cheers,

Kris

----- Original Message -----
From: "Kris Warkentin" <address@hidden>
To: <address@hidden>
Sent: Thursday, January 03, 2002 10:03 AM
Subject: ld dumping core on large objects when there are unresolved refs


> I was hoping to find out if anyone else had observed this.  I looked the
the
> mailing list archives but didn't immediately see anything.  A customer
gave
> us a number of large object files that, if linked, produce a valid
> executable.  If the linker command line is missing one of the objects,
> rather than getting unresolved references, we just dump core.  I'm trying
to
> get a reproducable case with code that I can actually compile (so I can
see
> if the problem exists for other platforms than QNX).
>
> Anyway, it's coring in the bfd lib when it tries to do a 16 bit endian
swap
> on some memory reference that is out of bounds.  Anyone seen anything like
> this?
>
> cheers,
>
> Kris
>
> ``To use: Apply shampoo to wet hair. Massage to lather, then rinse.
> Repeat.''
> ---A typical hair-washing algorithm that fails to halt
>