pc32 -> plt32 conversion and related questions

[H.J. Lu]

On Thu, Jun 17, 2021 at 8:16 AM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 17.06.2021 17:13, H.J. Lu wrote:
> > On Tue, Jun 15, 2021 at 6:42 AM Jan Beulich <jbeulich@suse.com> wrote:
> >>
> >> H.J.,
> >>
> >> alongside the question of what non-zero addends mean for certain
> >> relocation types, I came to notice that this conversion may be
> >> done in cases where it would better be avoided. I have the draft
> >> patch below (still lacking a test case and ChangeLog entry), and
> >> I particularly wonder whether the information propagation
> >> approach to md_estimate_size_before_relax() is acceptable, or
> >> whether you have other (better) suggestions.
> >>
> >> While playing with this (and in particular the code that I mean
> >> to convert into a testcase) I came to further notice that there
> >> is an inconsistency in whether relocations for branches get
> >> emitted for locally defined symbols:
> >>
> >>         .text
> >>         .global _start, func
> >> _start:
> >>         call    func    # gets converted to PLT32 reloc (and would be subject to preemption even when left as PC32), ...
> >>         jc      func    # ... while this and ...
> >>         jmp     func    # ... this get resolved locally, unless ...
> >>
> >>         # ... this directive is enabled (or -mshared gets passed)
> >>         #.section .text.lib, "ax", @progbits
> >> func:
> >>         ret
> >>         .type func, @function
> >>         .size func, .-func
> >>
> >> In 2.30 (i.e. before the pc32 -> plt32 conversion) the CALL
> >> yields a PC32 reloc, so the issue isn't directly related to that
> >> change. But given the effect -mshared has on JMP and Jcc, do you
> >> agree that CALL should be handled consistently with JMP/Jcc here?
> >> Not the least to match the documentation of -mshared:
> >>
> >> "On ELF target, the assembler normally optimizes out non-PLT
> >>  relocations against defined non-weak global branch targets with
> >>  default visibility."
> >
> > Yes, CALL should be handled like JMP/Jcc.
>
> And this means in the case above no relocation without -mshared?

Yes.

> >> It doesn't mention that there's a difference between different
> >> kinds of branches.
> >>
> >> And then, still in this same context, I did also notice that the
> >> linker complains about e.g. PC32 relocs when building a shared
> >> library even when that's a x32 one (suggesting to rebuild with
> >> -fPIC). 32-bit relocations can't overflow in that ABI, so wouldn't
> >> such errors better be suppressed there?
> >
> > It can overflow in x32 since x32 is totally implemented on software
> > and there is no address wraparound.
>
> But that is to be dealt with by the dynamic linker, isn't it? The
> static linker should assume everything fits in the 2Gb window.

What can the dynamic linker do? We are talking about shared
libraries here.  The distance between a shared library and
another shared library/executable can be > 2GB.

-- 
H.J.