This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Strange reloc problem in large MIPS C++ programs


I've been chasing a nasty problem that recently started showing up in
a large (multi MB) mips-netbsdelf program.  It uses C++, that may be
relevant.

We were using GCC 3.3.3 and binutils 2.14.  (Note that NetBSD has a
habit of lagging toolchain versions.)

The symptom is that at some point we'd add a bit of code to the
working program, and it would then start to crash in odd places, for
example in the static object constructors that run prior to main().
The code change that triggers the failure would be unrelated to the
spot that breaks.

After a lot of debugging I discovered that the code was calling to an
invalid (not mapped) address.  Digging deeper, it turned out it was
trying to call some function -- perhaps operator new -- that was
present both in the main executable and in some shared library.

In the broken version, by the time the call happened, the pointer
table containing that function address would have a bad value in it.
Specifically, it would contain the sum of the two addresses of the two
copies of that function...

If I did a "readelf -r" I would see the function in question show up
in the relocs.  On the other hand, in a good binary it would not be
there.

Rather than dig through ld and bfd, I tried the current binutils
(2.18).  That appears to cure the problem.

My question: does this sound like a familiar problem that was indeed
fixed between 2.14 and 2.18?  Or does the change to 2.18 simply move
the bug to a different point and it will bite me later?  If the
latter, any suggestions where I should start debugging?

	paul


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]