This is the mail archive of the
mailing list for the binutils project.
Re: h8300-hms-ld segfaults (with a small testcase)
- From: "Max Bowsher" <maxb at ukf dot net>
- To: "Daniel Jacobowitz" <drow at mvista dot com>,"Kazu Hirata" <kazu at cs dot umass dot edu>
- Cc: <binutils at sources dot redhat dot com>,<paulc at senet dot com dot au>,<amodra at bigpond dot net dot au>
- Date: Mon, 16 Dec 2002 16:27:53 -0000
- Subject: Re: h8300-hms-ld segfaults (with a small testcase)
- References: <firstname.lastname@example.org> <20021216155749.GA14940@nevyn.them.org>
Daniel Jacobowitz <email@example.com> wrote:
> On Mon, Dec 16, 2002 at 10:50:14AM -0500, Kazu Hirata wrote:
>> The problem of h8300-hms-ld doing a segfault is caused by the
>> attached files. The original linker script is provided by Paul
>> Clark and later reduced by me. Removing "OUTPUT_FORMAT(srec)"
>> prevents the segfault.
> Linking directly to SREC always turns up bugs... usually, they involve
> accessing the target-specific parts of the hash table when in the
> wrong target's code.
In this case, a generic hash table is created, then treated as a h8300
>> The problem started occuring with the following patch:
> That seems very unlikely. Could you narrow it down further - for
> instance, does reverting the part for coff-h8300.c fix it? What do
> GDB and valgrind have to say about the crash?
> (If you've never used valgrind I highly recommend it for this sort of
I have valground (is that a verb :-) this, and found out that the problem
actually existed before, but only began to cause segfaults when memory
allocation was reworkd in bfd between 2.12.1 and 2.13 (the bfd_alloc /
A perfectly acceptable workaround for now is to link to coff, and then
objcopy to srec. Obviously, it would be nice for this to be fixed,
PS: I'm *not* on the binutils@ list.