在 2022/8/31 下午9:41, Xi Ruoyao 写道:
> Some self review:
>
> On Wed, 2022-08-31 at 21:22 +0800, Xi Ruoyao wrote:
>> -             /* For pcalau12i + jirl.  */
>> -             h->needs_plt = 1;
>> -             if (h->plt.refcount < 0)
>> -               h->plt.refcount = 0;
>> -             h->plt.refcount++;
>> +             /* Check if it's a jirl instruction.  */
>> +             bfd_byte *contents = elf_section_data (sec)->this_hdr.contents;
>> +             uint32_t insn = 0;
>> +
>> +             if (contents || bfd_malloc_and_get_section (abfd, sec, &contents))
>> +               memcpy(&insn, contents + rel->r_offset, sizeof(insn));
>> +
>> +             if ((insn & 0xfc000000) == 0x4c000000)
> This is tricky.  But in commit 42bd525 we already started to rely on
> undocumented %pc_{hi20,lo12} behavior: if you just apply them "as
> documented" to the pcalau12i/jirl pairs the result will be absolutely
> wrong.  And 42bd525 behavior is not fully correct: if you just write
>
> pcalau12i $t0, %pc_hi20(data)
> ld.d, $t0, $t0, %pc_lo12(data)

Do you have a test case?

>
> With 42bd525, the BFD linker generates a "PLT for data" (absolutely
> nonsense), and destroys the ld.d instruction.  All of these buggy
> behavior happens silently, the user will only find something wrong when
> the linked program crashes.
>
> I'm not sure if checking JIRL (i. e. the behavior of a relocation now
> depends on the instruction where it's applied) is a good idea.  Maybe we
> should use the following instead of pcalau12i/jirl:
>
> pcaddu18i $t0, %b16_hi20(func)
> jirl $ra, $t0, %b16(func)
>
> ("b16_hi20" is a hypothetical thing here.)  This will make things less
> tricky, and also expand the range to 128 GiB.

It doesn't make sense for only "pcaddu18i + jirl" to access 128G.What we 
need is a jump that can access ±2G, just like any other pc-relative instructions can access ±2G.