[PATCH][GOLD] Fix remaining issues in stub-generations.
Ian Lance Taylor
iant@google.com
Tue Dec 1 23:29:00 GMT 2009
"Doug Kwan (關振德)" <dougkwan@google.com> writes:
> 2009-11-29 Doug Kwan <dougkwan@google.com>
>
> * arm.cc: Update comments about interworking and stub generation.
> (Target_arm::Scan::symbol_needs_plt_entry): Treat un-typed symbols
> as functions.
> (Target_arm::Relocate::reloc_is_non_pic): Update list of relocations
> considered as non-PIC.
> (Arm_relocate_functions::base_abs): Fix formatting.
> (Arm_relocate_functions::got_prel): Fix comment. Change interface
> of function to use GOT entry address instead of offset.
> (Target_arm::Scan::global): Remove code to create dynamic symbols for
> relative branches.
> (Target_arm::Relocate::relocate: Use 0 instead of false since function
> takes unsigned integer instead of boolean.
> + // We need to treat symbols with no type as functions to allow
> + // assembly functions without proper symbol type annotations.
> return (!parameters->doing_static_link()
> && (sym->type() == elfcpp::STT_FUNC
> - || sym->type() == elfcpp::STT_ARM_TFUNC)
> + || sym->type() == elfcpp::STT_ARM_TFUNC
> + || sym->type() == elfcpp::STT_NOTYPE)
I don't think this is a good idea. No other target acts this way. It
can fail badly if there is a symbol with no type which is not a
function. The correct fix is to annotate the assembly code.
It's fine to force a PLT entry when using a reloc which implies one,
such as R_ARM_PLT32_ABS. But I don't think it's a good idea in
general. If this is being used for a reloc which implies a PLT entry,
then the function should have a different name and a different
comment.
The rest of this patch is OK.
Thanks.
Ian
More information about the Binutils
mailing list