This is the mail archive of the 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: Mr Taylor surely understands ld

> There are some basic rules of software engineering that we somehow take for
> granted. For instance, a .h file contains declarations, and a .c file contains
> executable code. This is not the case with 'ld'. The file 'coff.h' contains
> executable code that is included TWICE (yes, the same file) in the code of
> 'ld' with different #defines as input. This works because all the functions
> in that file are declared static and accessed by several indirection tables. 

What would you prefer, that there be multiple copies of the code?  Then, when
they get out of sync, how do you tell which one is right?  How do you ensure
that a fix in one version is properly carried over into the other versions?

> Problem is, most debuggers get confused with this... not to speak of the poor 
> guy *reading* that code!

Yea, debuggers may be a problem, but it doesn't really take that much figuring
out for a person to grok what's going on.

> But it is the whole philosophy behind this that is flawed. 
> Mr Taylor writes:
> > ...the linker is able to generate an object file
> > format which is different from the input file formats.  For example,
> > this permits the linker to directly generate S-record output without
> > requiring a convertor.
> But WHY do we have to put the convertor and the linker in the SAME PROGRAM!!!
> In my view of things, it would be much better to have an easy to understand
> convertor to be used by systems programmers when they need S records, than
> to overload the linker with YET ANOTHER LEVEL OF COMPLEXITY!!!

Actually, although being able to handle multpile types of binary files
concurrently is a virtue, I don't see that as the main thing about BFD.
With BFD, to support a new file format, you only have to write the back
end for that format.  Then, all the tools will work for you.  You don't
have to write a new assembler, linker, stripper, archiver, name lister,
object file dumper, object file converter, etc.  Or, going at it another
way, if you write a new tool, it instantly supports all the BFD object
formats, not just the one you need at the moment.  I see this as the main
advantage to BFD, and converting formats on the fly is just an added bonus.

Of course, this is the ideal situation.  In reality, the back ends aren't
as clean as would be nice, and new file formats may have information that
the BFD abstraction doesn't, so efforts to carry this inforamtion along if
the output format is the same as the input format ceratinly complicates things
a lot.  Writing a new back end isn't a particularly trivial thing to do, but
if it is similar to an existing format it isn't too difficult to copy and
modify the existing code.  Interfacing to the BFD routines instead of writing
at the raw file level is slightly more cumbersome, but that's mostly because
you have to abstract your thinking from the representation of a particular
format.  In fact, though, the BFD interface is conceptually very similar to
COFF, so writing to BFD instead of just COFF is only slightly harder.

marcus hall
Lucent Technologies
For help on using this list, send a message to
"" 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]