This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: Proposed linker feature
- From: Alan Modra <amodra at gmail dot com>
- To: Jerome Berryhill <JBB at JeromeBerryhill dot com>
- Cc: binutils at sourceware dot org
- Date: Sat, 19 Apr 2014 12:09:19 +0930
- Subject: Re: Proposed linker feature
- Authentication-results: sourceware.org; auth=none
- References: <DE50AA188D7947628A3D1FC2011B0F26 at SYSTEMAX>
On Fri, Apr 18, 2014 at 06:02:45PM -0700, Jerome Berryhill wrote:
> I do a lot of performance benchmarking on HPC workloads under linux,
> in C or Fortran. I often want to produce a small piece of code from
> a larger one, either to use it for testing or performance
> benchmarking, or to isolate a compiler issue. It would be extremely
> useful to be able to produce a binary executable even if some or all
> the symbolic references were not resolved. That is, it would be
> helpful if, instead of issuing a linker error message and
> terminating when it can't find every last symbol referenced in an
> input elf, the linker would produce an output elf that would crash
> (or call a graceful exit) if the unresolved reference showed up in
> the execution path. Presumably, this would only happen if a
> particular linker switch were present.
ld has a --noinhibit-exec option, which is supposed to give you a
binary after hitting errors. However most (if not all) target
relocate_section functions return false on at least some non-fatal
errors, and that stops further relocation processing.
You may be OK for undefined symbol errors, depending on your target.
For instance, I think the powerpc backends will generally continue
relocation processing on undefined symbol errors. Note that the code
at first sight looks like it will might return false on calling
info->callbacks->undefined_symbol in elf-bfd.h RELOC_FOR_GLOBAL_SYMBOL
but on looking at the undefined_symbol function in ldmain.c you'll see
it doesn't ever return false.
--
Alan Modra
Australia Development Lab, IBM