This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: coff-h8300 bfd bug (Electric Fence info)
- From: Max Bowsher <maxb at ukf dot net>
- To: "Svein E. Seldal" <Svein dot Seldal at solidas dot com>
- Cc: Max Bowsher <maxb at ukf dot net>, <binutils at sources dot redhat dot com>
- Date: Mon, 2 Dec 2002 10:35:34 +0000 (GMT Standard Time)
- Subject: Re: coff-h8300 bfd bug (Electric Fence info)
On Mon, 2 Dec 2002, Svein E. Seldal wrote:
SES> Just a suggestion:
SES>
SES> I had a similar problem recently. I was trying to compile an application
SES> that utilized libbfd.a. It behaved *very* strange, as I keep getting
SES> segfaults all the time. I ran gdb on it and discovered that bfd_openr()
SES> somehow failed. Or didt fail... The return pointer was valid and all,
SES> but one of the pointer's members kept getting zeroed out. This member
SES> was the cause of my segfault. The problem was that the pointer's member
SES> was perfectly allright *inside* bfd_openr(), but as soon as it returned
SES> to my application, some of the members got changed!
SES>
SES> Well, my point is that the problem went away when I replaced my RH8.0
SES> default binutils&gcc tools with my own custom compiled binutils-2.13.1
SES> and gcc-3.2.1! I suspect the RH8.0 tools is unstable... Maybe you have
SES> a similar problem.
It's possible, but unlikely - you see, I've tested this on both Cygwin and
RH8.0. However... they both share a common factor: gcc-3.2 ... I wonder
maybe I should install gcc-3.2.1 .
However, what I've found so far would seem to indicate that the problem is
bitrot in a little used corner of bfd. The fact that binutils-2.12 does
not segfault in the exact same circumstances when compiled in the exact
same environment seems to support this - unless its a very weird compiler
bug.
Max.