[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gcl-devel] Mingw32 BFD
From: |
Mike Thomas |
Subject: |
Re: [Gcl-devel] Mingw32 BFD |
Date: |
Tue, 23 Jul 2002 17:50:56 +1000 |
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
>