This is the mail archive of the 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]

Re: coff-h8300 bfd bug (Electric Fence info)

On Mon, 2 Dec 2002, Svein E. Seldal wrote:

SES> Just a suggestion:
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> 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


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