Re: h8300-hms-ld segfaults (with a small testcase)

[Daniel Jacobowitz <drow at mvista dot com>]

On Mon, Dec 16, 2002 at 04:27:53PM -0000, Max Bowsher wrote:
> Daniel Jacobowitz <drow@mvista.com> wrote:
> 
> > On Mon, Dec 16, 2002 at 10:50:14AM -0500, Kazu Hirata wrote:
> >> Hi,
> >>
> >> 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
> extended one.
> 
> >> The problem started occuring with the following patch:
> >>
> >> http://sources.redhat.com/ml/binutils-cvs/2002-04/msg00030.html
> >
> > 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
> > bug.)
> 
> 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 /
> bfd_malloc change).
> 
> 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,
> eventually, though.

What should eventually happen is probably that the .vector section
should be associated with some input BFD and searched for when it's
needed, since we can't use the hash table.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer