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] |
On Wed, Jan 12, 2011 at 9:22 AM, Vladimir Simonov<sv@sw.ru> wrote:2.2 Leave gcc untouched and do the same work in binutils. If --enable-gold specified in binutils configure options we create simple wrapper which will strip --use-ld=LINKER_NAME from linker options and call appropriate linker. Default linker is defined by configure options. The wrapper is installed as ld. The wrapper code should be located in gold directory and built (and installed as ld) if "make" visits gold directory.
Both have pro and contra. 2.2 - decreases binutils install size, leaves gcc untouched but adds additional "exec" during link process.
I can try to do any. What do you think which is better?
I don't think we should go with 2.2. GCC driver already sets
COLLECT_GCC=/usr/gcc-4.6/bin/gcc COLLECT_LTO_WRAPPER=/usr/gcc-4.6/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper COLLECT_GCC_OPTIONS='-c' '-v' '-mtune=generic' '-march=x86-64'
Why not add
COLLECT_LINKER=..............
which can be set by "gcc -flinker=ld.gold|ld.bfd"?
IMO duality in linker implementation should be hidden from gcc as much as possible. Right now in plain gcc sources we already have: [gcc-4.5.2]$ grep -i -E "\<gold\>|_gold" * -r|wc -l 706
The more options we add to gcc the more problems in gcc version switch(back and forward) appear for gcc users.
Regards Vladimir Simonov
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |