Re: [PATCH][GOLD] Fix remaining issues in stub-generations.

[Ian Lance Taylor <iant at google dot com>]

"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