Re: [Gcl-devel] Mingw32 BFD

[Mike Thomas]

Hi Camm.

> I'll try to respond more fully later,

Thanks, I would appreciate the printout from the program I sent to help get
a feel for what should be happening.  This email is just to keep you
informed of progress so far.


> 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.

I'm not in touch with this sort of stuff - does this mean in effect that we
are using an experimental feature?

>    Options going forward:
> a) To submit patches to binutils

If, (with your guidance) we can manage to fix the problem this would be a
great move I think.

To put this in a realistic perspective, patching the bfd library is about as
far from my field of programming knowledge as you can go.  I keep repeating
to myself "You have read "Zen and the Art of Motorcycle Maintenance" so you
know this is good!"

> b) To use our own patched version, a la gmp

Unless you have a good reason for doing this I think that this is not really
good as it might extra work in the long run.


> c) To try to use bfd_relocate_section, though this cannot be
>    called in a completely portable way, and will require arch specific
>    arguments.

I don't know anything about how to use libbfd.  This is your call.


> 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.

I don't want this outcome, I would prefer to leave the Win32 version of GCL
on the same footing as the Unix versions in this respect.


>
> 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).

I have now managed to build debug versions of libbfd et al and will report
back on what I can find out with gdb.


>
> 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.

We can discuss this further when I have acquired more understanding of what
I am doing.


Cheers

Mike Thomas.



>
> 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
>