[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gcl-devel] Mingw32 BFD
From: |
Camm Maguire |
Subject: |
Re: [Gcl-devel] Mingw32 BFD |
Date: |
16 Jul 2002 18:50:27 -0400 |
Hi Mike! I'll try to respond more fully later, but I've been so busy
that I thought best to at least respond in brief now:
1) This is almost certainly a bfd issue.
bfd_get_relocated_section_contents has not been finished on some
platforms. So far, it works on 6 or maybe 7 of the 11 Debian
architectures, so I guess its still worthwhile pursuing it.
Options going forward:
a) To submit patches to binutils
b) To use our own patched version, a la gmp
c) To try to use bfd_relocate_section, though this cannot be
called in a completely portable way, and will require arch specific
arguments.
d) To provide fasldlsym.c as an option where binutils isn't
yet working -- I expect a problem with the new maxima build system
here, but not the old. In brief, one cannot load .o files and then
find them later in a saved_image.
2) I often build my own bfd and iberty libs with -g in my working
directory, and then use export C_INCLUDE_PATH=.../bfd:.../include ;
export LIBRARY_PATH=.../bfd:.../libiberty; before building gcl.
Then one can debug in gdb right into the bfd routines. (in the bfd
source directory, CFLAGS=-g ./configure && make, as in the
libiberty source directory).
3) I'd bet that coff_i386_reloc() requires output_bfd to be non-null,
though I haven't checked yet. One sets this to NULL when not
requesting relocateable output, i.e. output which in turn can be
passed to a linker for further relocation later, as is the case
here. Trouble is, many routines assume they will never be called
this way. Perhaps we can find a way to call with relocateable
output, and do something else for a final link later.
4) I have a sfaslbfdd.c for debugging, which basically just compares
the old and new way of doing the relocations (on i386 and sparc
only) and reports any differences. Won't help here of course.
Take care,
"Mike Thomas" <address@hidden> writes:
> Hi Camm.
>
> The problem is occuring in "fasload()" in "sfaslbfd.c" at:
>
> ......
> if (!bfd_get_relocated_section_contents(b,&link_info,&link_order,
> (void *)s->output_section->vma,0,q))
> ......
>
> A SIGSEGV in bfd_getl32(), called in turn from
> coff_i386_reloc(),
> bfd_perform_relocation(),
> bfd_generic_get_relocated_section_contents() and at the top of the
> stack,
> bfd_get_relocated_section_contents() in the above line.
>
> The struct arguments to the function all seem to be sensible (ie not
> containing random data), but never-the-less it looks like there is an
> initialization problem. Poking around on the function call stack crashes
> gdb so it's pretty messy.
>
> Have you any ideas? I tried executing "si::build-symbol-table" manually
> before trying to load the object file, but the same problem
>
> What a convoluted chase it has been so far. It took me ages to realise that
> link_info.hash is actually initialised via the INITFORM makefile macro when
> "raw_gcl.exe" is built!
>
> As my home computer just died I won't be able to touch this over the
> weekend.
>
> Cheers
>
> Mike Thomas.
>
>
>
> _______________________________________________
> Gcl-devel mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/gcl-devel
>
>
--
Camm Maguire address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah