This is the mail archive of the cygwin@sourceware.cygnus.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: bfd, ld, and dlltool patches


OK, well, I just saw the test message from this morning, but I haven't seen
any sign of the two previous mailings of this message from Wednesday and
Thursday.  If they did actually make it to the mailing list, I'm sorry for
the repeat, and would somebody please tell me to stop! :-)


I have been doing some work in my spare time (actually it was a while ago
on b17.1) to build a cross-compiler environment to generate NT code on a
Sun and interwork with MS DLLs.  To this end, I have about 350 lines of
patches to bfd and ld files, and 1200 lines of patches to dlltool.  These
have been forwarded to the b18 versions, although I haven't had time to
do any further development.

At this point, I can link with many of the microsoft .lib libraries.  The
remaining problem seems to be in handling some of the segment types where
ld complains that it is ignoring multiple instances of a segment, aparently
because of a mis-interpretation of communil data header information.   I
can produce a .lib that is almost acceptable to MS LINK, but it seems that
LINK wants the file names inside the archive to be identical, unlike the
dt0.o, dt1.o, etc. files produced by dlltool.  There isn't an obvious way
to get bfd to produce an archive with internal file names to be the same
even though it can handle this case in an existing archive just fine.  Perhaps
playing with storing the files in memory instead of in disk files would
be appropriate here, since the problem seems to be in that aspect.

Most of the changes to dlltool were to (nearly) eliminate the use of the
assembler to produce the .o files and to simply write the .o files directly
with bfd.  I have converted all the code to deal with generating the import
tables, but have not yet attacked the export tables.  I also generate an
import table terminator that is compatible with the MS .libs, so the
fixup.c kludges should no longer be necessary.

My question here is, does the list want to see the patches posted here or not?
If not, what mechanism would be appropriate?  Since b19 is forthcoming and
some of these changes may be useful for that, I'd like to get some of these
changes submitted for consideration by cygnus, and perhaps save them some
work if they haven't already done equivalent work.

The context diff is 1419 lines long...

marcus hall
Lucent Technologies
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]