Re: [Gcl-devel] Mingw32 BFD

[Camm Maguire]

Greetings!

"Mike Thomas" <address@hidden> writes:

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

OK, sent separately.

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

Or at least an uncompleted feature.  bfd in general appears to be
quite a moving target regarding API, etc.  Check out the info pages.
We've gotten some good mileage out of this approach so far, IMHO, but
in retrospect it might have been easier to try to go with the X
loading code.  That does seem so much bigger and more difficult,
though.  

The good news is that in playing with this stuff, I've at least gotten
a modest understanding of the relocation part of the code.  It should
not be difficult, I'd think, to come up with a coff i386 patch.
Getting it accepted is quite another thing, as the linker and other
programs use a quite different path through the bfd than we are using,
and so our patches might have unintended consequences elsewhere.

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

We can at least come up with something that would work for us.  I'll
try to find time to look at it at some point.

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

:-)  If you are interested, I have a debugging version of the sfaslbfd
you could look at, which compares the old and new relocation output.
I don't really know anything about bfd either -- all I really did was
to follow Dr. Schelter's code through a debugger, and then find out
where the analogous bits were stored in bfd in another debugger
session.  There could well be a better way out there.


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

I agree, in general.  Maybe it would be best to try to suggest a
patch, and see what level of complication arises on the binutils
mailing list.  The only good reason for b is that we are really using
bfd in a limited way which is quite unconventional.

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

I'd love to avoid this, as the code that is actually used by the
linker in this routine is far more involved, and appears to do
significant work apart from our main goal.

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

OK.  This brings to mind a comment I've read elsewhere about one of
gcl's strengths, and it is this ability to load .o files
interactively, dump the image, and then find them again when the image
is fired up.  Personally, I don't see why this is all that useful, as
compared to using the gcc linker to finally link your lisp compiled .o
files, but I do want to hold on to and extend advantages that gcl has
among people who use it regularly.

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

Great!

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

OK

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

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah