public inbox for gas2@sourceware.org
 help / color / mirror / Atom feed
From: Ian Lance Taylor <ian@cygnus.com>
To: artk@congruent.com
Cc: gnu@cygnus.com, erich@uruk.org, gas2@cygnus.com, bfd@cygnus.com,
	gnu@cygnus.com
Subject: Re: traditional Intel & Microsoft formats...
Date: Fri, 11 Nov 1994 08:31:00 -0000	[thread overview]
Message-ID: <199411111631.LAA06035@sanguine.cygnus.com> (raw)
In-Reply-To: <9411111311.AA12300@Congruent.COM>

   Date: Fri, 11 Nov 94 08:11:00 est
   From: artk@congruent.com (Arthur Kreitman)

   >   By the way, it looks to me like Windows DLL linking is remarkably like
   >   dynamic linking on SVR4 or SunOS.  Since the GNU Linker now supports
   >   dynamic linking (which was, indeed, a fair bit of work), making it
   >   handle DLL's is probably not as big a job as you think.

      I don't think that the mechanism used to support dll's is similar
   to sunos shared library support in any way.  Their capabilities
   differ significantly.  

I don't know that much about dll's.  Could you give a brief summary of
why they are so much more difficult than, say, ELF dynamic libraries?
The GNU linker currently has full support for ELF dynamic libraries.

   >   The way to support any of these formats is to write a new BFD
   >   back-end.  It's really pretty easy.  Look at one of the simple ones
     That's the easiest part of supporting the Microsoft formats.  There are
   new section types that have to be generated, import tables, export tables,
   resources.  BFD get you alot closer, but I would guess that it will
   that more resources to get the current BFD to completely support MS
   executables then it took to add sunos dynamic linking.

It's true that the BFD paradigm does not represent certain things
well.  For example, MIPS ELF uses an unusual debugging format (ECOFF)
which requires linker support, as well as recording information like
how much an object file would be changed by compiling with different
values of the -G switch.  BFD can not represent this information
publically, but that does not mean that BFD does not help enormously
when writing a linker.  It just means that special routines are
required in that BFD backend.

      As an aside, do you know how much work was required to add 
   sun dymanic linking.

I did all the work to support SunOS dynamic linking.  I did it mostly
on my own time, since Cygnus did not have a customer for it.  The
hardest part was reverse engineering the largely undocumented format.
I don't want to pass over that too lightly, because it was quite
difficult.  On the other hand I am assured by friends at Microsoft
that the object file format is reasonably well described on some CD or
set of CD's which is available for $195.

Once I understood the format, it probably took me about a week all
told to write the linker support.  The ELF dynamic linking code had
already been written, largely by Eric Youngdale, so I was able to use
that as a guide.  You could add in a couple of days I spent early in
the process to add some calls to BFD to read the dynamic symbol table
and the dynamic relocs, so that I could examine them with objdump
while I tried to figure out what the runtime linker did with them.

Ian


  reply	other threads:[~1994-11-11  8:31 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1994-11-09  8:05 Erich Stefan Boleyn
1994-11-09  8:59 ` Arthur Kreitman
1994-11-09  9:41   ` Erich Stefan Boleyn
1994-11-09  9:56   ` DJ Delorie
1994-11-09  9:57   ` Ken Raeburn
1994-11-09 10:33     ` DJ Delorie
1994-11-09 11:56       ` Erich Stefan Boleyn
1994-11-09 10:49     ` Arthur Kreitman
1994-11-09 12:02       ` Erich Stefan Boleyn
1994-11-10  8:22     ` Richard Stallman
1994-11-10  8:11   ` Richard Stallman
1994-11-10  9:35     ` Erich Stefan Boleyn
1994-11-10 22:53 ` John Gilmore
1994-11-10 23:25   ` John Gilmore
1994-11-11  5:34   ` Arthur Kreitman
1994-11-11  8:31     ` Ian Lance Taylor [this message]
1994-11-11 10:21   ` Erich Stefan Boleyn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=199411111631.LAA06035@sanguine.cygnus.com \
    --to=ian@cygnus.com \
    --cc=artk@congruent.com \
    --cc=bfd@cygnus.com \
    --cc=erich@uruk.org \
    --cc=gas2@cygnus.com \
    --cc=gnu@cygnus.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).