[3/3] LoongArch: Reword message for unresolvable PC-relative relocs

  If we hit such a bad reloc, it means the programmer has somehow wrongly
instructed the compiler to generate PC-relative relocs against external
symbols.  "Recompiling with -fPIC" (or -fPIE) is just misleading.

Signed-off-by: Xi Ruoyao <xry111@xry111.site>
---
 bfd/elfnn-loongarch.c                                     | 4 ++++
 ld/testsuite/ld-loongarch-elf/bad_pcala_hi20_global.d     | 2 +-
 ld/testsuite/ld-loongarch-elf/bad_pcala_hi20_global_pie.d | 2 +-
 ld/testsuite/ld-loongarch-elf/bad_pcala_hi20_weak.d       | 2 +-
 ld/testsuite/ld-loongarch-elf/bad_pcala_hi20_weak_pie.d   | 2 +-
 ld/testsuite/ld-loongarch-elf/bad_pcrel20_s2_global.d     | 2 +-
 ld/testsuite/ld-loongarch-elf/bad_pcrel20_s2_weak.d       | 2 +-
 7 files changed, 10 insertions(+), 6 deletions(-)
  

On 12/13/24 1:53 PM, Xi Ruoyao wrote:
> If we hit such a bad reloc, it means the programmer has somehow wrongly
> instructed the compiler to generate PC-relative relocs against external
> symbols.  "Recompiling with -fPIC" (or -fPIE) is just misleading.
>
> Signed-off-by: Xi Ruoyao <xry111@xry111.site>
> ---
>   bfd/elfnn-loongarch.c                                     | 4 ++++
>   ld/testsuite/ld-loongarch-elf/bad_pcala_hi20_global.d     | 2 +-
>   ld/testsuite/ld-loongarch-elf/bad_pcala_hi20_global_pie.d | 2 +-
>   ld/testsuite/ld-loongarch-elf/bad_pcala_hi20_weak.d       | 2 +-
>   ld/testsuite/ld-loongarch-elf/bad_pcala_hi20_weak_pie.d   | 2 +-
>   ld/testsuite/ld-loongarch-elf/bad_pcrel20_s2_global.d     | 2 +-
>   ld/testsuite/ld-loongarch-elf/bad_pcrel20_s2_weak.d       | 2 +-
>   7 files changed, 10 insertions(+), 6 deletions(-)
>
> diff --git a/bfd/elfnn-loongarch.c b/bfd/elfnn-loongarch.c
> index 5d252bcccb9..93368275b46 100644
> --- a/bfd/elfnn-loongarch.c
> +++ b/bfd/elfnn-loongarch.c
> @@ -894,6 +894,10 @@ bad_static_reloc (struct bfd_link_info *info,
>         pic = _("; recompile with -fPIE");
>       }
>   
> +  if (r_type == R_LARCH_PCREL20_S2 || r_type == R_LARCH_PCALA_HI20)
> +    pic = _("; recompile with -mno-direct-extern-access and check the "
> +	    "symbol visibility");
> +
>     (*_bfd_error_handler)
>      (_("%pB:(%pA+%#lx): relocation %s against `%s` can not be used when making "
>         "%s%s"),

Perhaps the prompt here is not always appropriate. such as:
$ cat test.c

int a =1;
int main (void)
{
printf("%d\n",a);
}

$ gcc -fno-pic -c test.o
$ gcc -shared -o test test.o

Will get error message:
ld: test.o:(.text+0x10): relocation R_LARCH_PCALA_HI20 against `a` can 
not be used when making a shared object; recompile
with -mno-direct-extern-access and check the symbol visibility

If the user follows the prompts and uses "gcc -mno-direct-extern-access 
-c test.o" to compile and then link, an error will still be reported.
However, the problem is solved after recompiling and linking using "gcc 
-fpic -c test.o".

> diff --git a/ld/testsuite/ld-loongarch-elf/bad_pcala_hi20_global.d b/ld/testsuite/ld-loongarch-elf/bad_pcala_hi20_global.d
> index 6ecefd1d48a..fac02d036ba 100644
> --- a/ld/testsuite/ld-loongarch-elf/bad_pcala_hi20_global.d
> +++ b/ld/testsuite/ld-loongarch-elf/bad_pcala_hi20_global.d
> @@ -2,4 +2,4 @@
>   #source: bad_pcala_hi20_global.s
>   #target: [check_shared_lib_support]
>   #ld: -shared --defsym global_a=0x10 --defsym global_b=0x20
> -#error: .*: relocation R_LARCH_PCALA_HI20 against `global_b` can not be used when making a shared object; recompile with -fPIC
> +#error: .*: relocation R_LARCH_PCALA_HI20 against `global_b` can not be used when making a shared object; recompile with -mno-direct-extern-access and check the symbol visibility
  

On Wed, 2024-12-18 at 16:12 +0800, Lulu Cai wrote:

/* snip */

>  Perhaps the prompt here is not always appropriate. such as: $ cat test.c
>  
> 
> 
> 
>  int a =1;
>  int main (void)
>  {
>  printf("%d\n",a);
>  }
>  
> 
> 
> 
>  $ gcc -fno-pic -c test.o
>  $ gcc -shared -o test test.o
>  
> 
> 
> 
>   Will get error message:
>  ld: test.o:(.text+0x10): relocation R_LARCH_PCALA_HI20 against `a` can not be used when making a shared object; recompile
>  with -mno-direct-extern-access and check the symbol visibility

Ah I think I've got the point.  So if we are linking a DSO, we should
still suggest -fPIC (and the compiler will reject the combination -fPIC
-mdirect-extern-access anyway so we don't need to redundantly mention -
mno-direct-extern-access); if we are linking a PIE or PDE, we should
suggest -mno-direct-extern-access.

And in both cases we should also suggest checking symbol visibility, in
addition to check compiler flags.

Is my understanding correct?
  

On 12/18/24 5:00 PM, Xi Ruoyao wrote:
> On Wed, 2024-12-18 at 16:12 +0800, Lulu Cai wrote:
>
> /* snip */
>
>>   Perhaps the prompt here is not always appropriate. such as: $ cat test.c
>>   
>>
>>
>>
>>   int a =1;
>>   int main (void)
>>   {
>>   printf("%d\n",a);
>>   }
>>   
>>
>>
>>
>>   $ gcc -fno-pic -c test.o
>>   $ gcc -shared -o test test.o
>>   
>>
>>
>>
>>    Will get error message:
>>   ld: test.o:(.text+0x10): relocation R_LARCH_PCALA_HI20 against `a` can not be used when making a shared object; recompile
>>   with -mno-direct-extern-access and check the symbol visibility
> Ah I think I've got the point.  So if we are linking a DSO, we should
> still suggest -fPIC (and the compiler will reject the combination -fPIC
> -mdirect-extern-access anyway so we don't need to redundantly mention -
> mno-direct-extern-access); if we are linking a PIE or PDE, we should
> suggest -mno-direct-extern-access.
>
> And in both cases we should also suggest checking symbol visibility, in
> addition to check compiler flags.
>
> Is my understanding correct?

Agree, I think this is more appropriate.

>
  

On 12/18/24 5:00 PM, Xi Ruoyao wrote:
> On Wed, 2024-12-18 at 16:12 +0800, Lulu Cai wrote:
>
> /* snip */
>
>>   Perhaps the prompt here is not always appropriate. such as: $ cat test.c
>>   
>>
>>
>>
>>   int a =1;
>>   int main (void)
>>   {
>>   printf("%d\n",a);
>>   }
>>   
>>
>>
>>
>>   $ gcc -fno-pic -c test.o
>>   $ gcc -shared -o test test.o
>>   
>>
>>
>>
>>    Will get error message:
>>   ld: test.o:(.text+0x10): relocation R_LARCH_PCALA_HI20 against `a` can not be used when making a shared object; recompile
>>   with -mno-direct-extern-access and check the symbol visibility
> Ah I think I've got the point.  So if we are linking a DSO, we should
> still suggest -fPIC (and the compiler will reject the combination -fPIC
> -mdirect-extern-access anyway so we don't need to redundantly mention -
> mno-direct-extern-access); if we are linking a PIE or PDE, we should
> suggest -mno-direct-extern-access.

Just asking. I would like to inquire whether you are available or have 
any ideas about
sending out a new patch.

> And in both cases we should also suggest checking symbol visibility, in
> addition to check compiler flags.
>
> Is my understanding correct?
>
>
  

On Wed, 2024-12-25 at 10:04 +0800, Lulu Cai wrote:
> On 12/18/24 5:00 PM, Xi Ruoyao wrote:
> > On Wed, 2024-12-18 at 16:12 +0800, Lulu Cai wrote:
> > 
> > /* snip */
> > 
> > >   Perhaps the prompt here is not always appropriate. such as: $ cat test.c
> > >   
> > > 
> > > 
> > > 
> > >   int a =1;
> > >   int main (void)
> > >   {
> > >   printf("%d\n",a);
> > >   }
> > >   
> > > 
> > > 
> > > 
> > >   $ gcc -fno-pic -c test.o
> > >   $ gcc -shared -o test test.o
> > >   
> > > 
> > > 
> > > 
> > >    Will get error message:
> > >   ld: test.o:(.text+0x10): relocation R_LARCH_PCALA_HI20 against `a` can not be used when making a shared object; recompile
> > >   with -mno-direct-extern-access and check the symbol visibility
> > Ah I think I've got the point.  So if we are linking a DSO, we should
> > still suggest -fPIC (and the compiler will reject the combination -fPIC
> > -mdirect-extern-access anyway so we don't need to redundantly mention -
> > mno-direct-extern-access); if we are linking a PIE or PDE, we should
> > suggest -mno-direct-extern-access.
> 
> Just asking. I would like to inquire whether you are available or have
> any ideas about
> sending out a new patch.

I'll send v2 soon.