On Wed, Dec 2, 2015 at 2:44 PM, Ulrich Weigand <uweig...@de.ibm.com> wrote:
> Hello,
>
> this patch fixes support for the large code model with the ELFv2 ABI.
>
> The global entry point prologue currently assumes that the TOC associated
> with a function is less than 2GB away from the function entry point.  This
> is always true when using the medium or small code model, but may not be
> the case when using the large code model.
>
> This patch adds a new variant of the ELFv2 global entry point prologue that
> lifts the 2GB restriction when building with -mcmodel=large.  This works by
> emitting a quadword containing the distance from the function entry point
> to its associated TOC immediately before the entry point (this is done in
> rs6000_elf_declare_function_name), and then using a prologue like:
>
>         ld r2,-8(r12)
>         add r2,r2,r12
>
> In addition, if assembler support for this new relocation is detected,
> the compiler emits a R_PPC64_ENTRY reloc on the first instruction of
> this new prologue.  This will allow the linker to rewrite the prologue
> to the original form if it turns out at link time that the distance
> between entry point and TOC actually happens to be less than 2GB.
>
> The patch also introduces a new function rs6000_global_entry_point_needed_p,
> which is used instead of directly checking cfun->machine->r2_setup_needed.
> This allows handling global entry point prologues for C++ thunks.  This was
> previously done by having rs6000_output_mi_thunk set the r2_setup_needed
> flag, but this no longer works, since we now need to check whether we need
> a global entry point prologue in rs6000_elf_declare_function_name, which
> is already called *before* rs6000_output_mi_thunk.
>
> Finally, the patch removes use of the GNU local label extension ("0b")
> in favour of compiler-emitted internal labels.  This seems clearer now
> that the entry point code may be split across two different functions
> (rs6000_output_function_prologue vs. rs6000_elf_declare_function_name)
> and makes it simpler to move the location of the TOC delta quadword
> at some future time.  Also, it removes the implicit assumption that
> the system assembler supports this GNU extension, which I understand
> we don't assume anywhere else.
>
> Tested on powerp64le-linux.  Also tested bootstrap/regtest with an
> extra patch to switch the default code model to CMODEL_LARGE.  Tested
> both with an assembler supporting R_PPC64_ENTRY and with an assembler
> that doesn't support it.
>
> OK for mainline?
>
> Bye,
> Ulrich
>
> ChangeLog:
>
>         * configure.ac: Check assembler support for R_PPC64_ENTRY relocation.
>         * configure: Regenerate.
>         * config.in: Regenerate.
>         * config/rs6000/rs6000.c (rs6000_global_entry_point_needed_p): New
>         function.
>         (rs6000_output_function_prologue): Use it instead of checking
>         cfun->machine->r2_setup_needed.  Use internal labels instead of
>         GNU as local label extension.  Handle ELFv2 large code model.
>         (rs6000_output_mi_thunk): Do not set cfun->machine->r2_setup_needed.
>         (rs6000_elf_declare_function_name): Handle ELFv2 large code model.

Okay.

Thanks, David

Reply via email to