This is the mail archive of the
mailing list for the binutils project.
Re: h8300-hms-ld segfaults (with a small testcase)
On Mon, Dec 16, 2002 at 04:27:53PM -0000, Max Bowsher wrote:
> Daniel Jacobowitz <email@example.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.
MontaVista Software Debian GNU/Linux Developer