OSDN Git Service

When we converted ld-elf2flt from the shell script to C, one small nuance
authorDavid McCullough <davidm@snapgear.com>
Tue, 17 Aug 2010 04:25:26 +0000 (04:25 +0000)
committerDavid McCullough <davidm@snapgear.com>
Tue, 17 Aug 2010 04:25:26 +0000 (04:25 +0000)
commit5b93746b59c57c20334a90e07412361e2853bffe
treed062e79c2a9dd132406fa35569bf7eb3af6b7e31
parentb3e607fef92e676481ee7e86b8965d9094e80e41
When we converted ld-elf2flt from the shell script to C, one small nuance
was missed: argv[0] contains the full path only when invoked with the full
path.  This is not the same behavior for shell scripts as $0 is always the
full path to the script in question.  Most of the time this isn't an issue
as gcc will invoke all of its tools (like the linker) with a full relative
path to itself.  However, if we attempt to invoke the linker directly, we
can see misbehavior such as:
bfin-uclinux-ld.real: cannot open linker script file ./../lib/elf2flt.ld:
No such file or directory

So, to fix this, we lean on more libiberty functions.  Specifically, the
make_relative_prefix() function.  This function locates a full argv[0] by
scanning $PATH to see where it was invoked.  This might sound a little
dodgy, but this is fundamental to how gcc and binutils implement support
for their runtime relocation, so it can't break ld-elf2flt without first
breaking every one else ;).

In the fall out of this fix, we can cull a bunch of local code that does
custom path parsing.  So not only do we get to fix an annoying bug, we get
to shrink code in the process.

Signed-off-by: Steve Kilbane <steve@whitecrow.demon.co.uk>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
ld-elf2flt.c