This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: How feasible is it to port gold to mingw?


Greatwolf <gmane.greatwolf@mamber.net> writes:

>   how feasible would it be to port gold over to windows assuming someone 
> is willing to take on this workload? 

Feasible, but the result would be a different program.

>   What part of the code base in gold would likely need to be modified? 

You could keep much of:

archive.cc
binary.cc
common.cc
compressed_output.cc
cref.cc
defstd.cc
descriptors.cc
dirsearch.cc
errors.cc
expression.cc
fileread.cc
gc.cc
gold-threads.cc
icf.cc
incremental.cc
int_encoding.cc
mapfile.cc
options.cc
parameters.cc
plugin.cc
script-sections.cc
script.cc
stringpool.cc
timer.cc
version.cc
workqueue.cc
workqueue-threads.cc

You would have to completely rewrite:

dynobj.cc
dwarf_reader.cc
gold.cc
layout.cc
merge.cc
object.cc
output.cc
readsyms.cc
reduced_debug_output.cc
reloc.cc
resolve.cc
symtab.cc
target.cc
target-select.cc
arm.cc
arm-reloc-property.c
i386.cc
sparc.cc
x86_64.cc

I think you could pretty much discard:

attributes.cc
copy-relocs.cc
ehframe.cc

>   How much work would need to be done? Doesn't need to be precise; I'm 
> looking for a ballpark figure here. eg. would 20%, 50%, or 80% of the 
> code need to be change due to platform specific details?

80%.  The files you have to change are the hard ones.

>   What sort of technical knowledge would one need to be able to perform 
> this task?

Detailed knowledge of both COFF and ELF, and what COFF and ELF linkers
have to do.  Also detailed knowledge of how gold works.

> I do have a few other questions though. It's unclear to me at this point 
> whether gold produces the final executable (that's written to disk) via 
> services provided by binutils or if it does it directly by itself. If 
> gold does this by itself, can't I extend the relevant classes that do 
> this to handle PE-Coff directly as well? Why would I not want to do this?

gold produces the final executable itself.  You can't extend the code to
handle PE-COFF directly because PE-COFF is different from ELF, and
requires a different strategy for efficient linking.  At a high level,
all linkers do the same thing.  In detail, they do different things.  If
you want efficiency, you have to care about the details.  For some more
background see my paper in the 2008 gcc summit:
http://ols.fedoraproject.org/GCC/Reprints-2008/taylor-reprint.pdf

> Also, would this be the most appropriate place to post future questions 
> I'll have regarding this endevor? I didn't get much intial response to my 
> post (maybe due to lack of knowledge, interest or both?). What can I do 
> to ensure I have a higher chance of getting a helpful response?

This is the right place to ask questions about gold.  You may find more
interest in, and knowledge about, PE-COFF over on one of the cygwin or
mingw lists.  I will certainly answer any specific question about gold;
whether I answer a general question depends on how much time I have
available.

If you follow Joseph's suggestion, then you are in effect converting
PE-COFF to ELF, linking it as ELF, and converting back.  The key to that
would be ensuring that you can represent all relevant aspects of PE-COFF
in ELF.  In particular PE-COFF has a different, somewhat simpler, model
of dynamic linking.

A cleaner and more efficient approach, from my point of view, would be
throw away all the ELF stuff and just rewrite a PE-COFF linker from
scratch.  That would certainly be more work.

Ian


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