This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [RFC/WIP] Add plugin infrastructure to ld.
- From: Ian Lance Taylor <iant at google dot com>
- To: Dave Korn <dave dot korn dot cygwin at gmail dot com>
- Cc: "binutils\ at sourceware dot org" <binutils at sourceware dot org>
- Date: Thu, 09 Sep 2010 14:46:30 -0700
- Subject: Re: [RFC/WIP] Add plugin infrastructure to ld.
- References: <4C894312.7000609@gmail.com>
Dave Korn <dave.korn.cygwin@gmail.com> writes:
> This, of course, is the easy bit. The more complex part is what I'd like to
> ask if anyone else has been thinking about or has any advice or suggestions:
> how to make LD play correctly with the plugin API. I'm not even certain that
> their modes of operation are going to be commensurate enough to make them fit,
> so I wrote this framework as a testbed to try and prove the concept.
As far as I know the plugin framework should work OK with GNU ld. It
was certainly designed with that in mind.
> For instance, it seems to me that LD has many locations that open input
> files, all of which error out if they fail to find their file, and all of
> which would need patching to call the 'claim files' hook and leave the file
> alone but still not error out if the file got claimed.
I'm not sure why you say there are many places that open input files.
As far as I know they are all opened by ldfile_try_open_bfd. Note that
linker scripts are not relevant to the plugin.
> I'm even less certain
> if LD's way of dealing with archives and archive members is commensurate
> enough with GOLD's to be compatible.
There is really only one way to handle archives and archive members, so
it should be pretty much the same.
Ian