gcl-devel
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]