This is the mail archive of the 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: Proposed linker feature

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

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