2022-07-19 01:20:46 +00:00
|
|
|
/* Startup code compliant to the ELF LoongArch ABI.
|
2023-01-06 21:08:04 +00:00
|
|
|
Copyright (C) 2022-2023 Free Software Foundation, Inc.
|
2022-07-19 01:20:46 +00:00
|
|
|
This file is part of the GNU C Library.
|
|
|
|
|
|
|
|
The GNU C Library is free software; you can redistribute it and/or
|
|
|
|
modify it under the terms of the GNU Lesser General Public
|
|
|
|
License as published by the Free Software Foundation; either
|
|
|
|
version 2.1 of the License, or (at your option) any later version.
|
|
|
|
|
2022-08-22 13:21:53 +00:00
|
|
|
In addition to the permissions in the GNU Lesser General Public
|
|
|
|
License, the Free Software Foundation gives you unlimited
|
|
|
|
permission to link the compiled version of this file with other
|
|
|
|
programs, and to distribute those programs without any restriction
|
|
|
|
coming from the use of this file. (The GNU Lesser General Public
|
|
|
|
License restrictions do apply in other respects; for example, they
|
|
|
|
cover modification of the file, and distribution when not linked
|
|
|
|
into another program.)
|
|
|
|
|
|
|
|
Note that people who make modified versions of this file are not
|
|
|
|
obligated to grant this special exception for their modified
|
|
|
|
versions; it is their choice whether to do so. The GNU Lesser
|
|
|
|
General Public License gives permission to release a modified
|
|
|
|
version without this exception; this exception also makes it
|
|
|
|
possible to release a modified version which carries forward this
|
|
|
|
exception.
|
|
|
|
|
2022-07-19 01:20:46 +00:00
|
|
|
The GNU C Library is distributed in the hope that it will be useful,
|
|
|
|
but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
|
|
|
|
Lesser General Public License for more details.
|
|
|
|
|
|
|
|
You should have received a copy of the GNU Lesser General Public
|
2022-08-22 13:21:53 +00:00
|
|
|
License along with the GNU C Library; if not, see
|
2022-07-19 01:20:46 +00:00
|
|
|
<https://www.gnu.org/licenses/>. */
|
|
|
|
|
|
|
|
#define __ASSEMBLY__ 1
|
|
|
|
#include <entry.h>
|
|
|
|
#include <sys/asm.h>
|
|
|
|
|
|
|
|
/* The entry point's job is to call __libc_start_main. Per the ABI,
|
|
|
|
a0 contains the address of a function to be passed to atexit.
|
|
|
|
__libc_start_main wants this in a5. */
|
|
|
|
|
|
|
|
/*
|
|
|
|
int
|
|
|
|
__libc_start_main (int (*main) (int, char **, char **),
|
|
|
|
int argc,
|
|
|
|
char **argv,
|
|
|
|
__typeof (main) init,
|
|
|
|
void (*fini) (void),
|
|
|
|
void (*rtld_fini) (void),
|
|
|
|
void *stack_end);
|
|
|
|
*/
|
|
|
|
|
|
|
|
ENTRY (ENTRY_POINT)
|
|
|
|
|
|
|
|
/* Terminate call stack by noting ra is undefined. Use a dummy
|
|
|
|
.cfi_label to force starting the FDE. */
|
|
|
|
.cfi_label .Ldummy
|
|
|
|
cfi_undefined (1)
|
|
|
|
or a5, a0, zero /* rtld_fini */
|
|
|
|
|
LoongArch: Fix the condition to use PC-relative addressing in start.S
A start.o compiled from start.S with -DPIC and no -DSHARED is used by
both crt1.o and rcrt1.o. So the LoongArch static PIE patch
unintentionally introduced PC-relative addressing for main and
__libc_start_main into crt1.o.
While the latest Binutils (trunk, which will be released as 2.40)
supports the PC-relative relocs against an external function by creating
a PLT entry, the 2.39 release branch doesn't (and won't) support this.
An error is raised:
"PLT stub does not represent and symbol not defined."
So, we need the following changes:
1. Check if ld supports the PC-relative relocs against an external
function. If it's not supported, we deem static PIE unsupported.
2. Change start.S. If static PIE is supported, use PC-relative
addressing for main and __libc_start_main and rely on the linker to
create PLT entries. Otherwise, restore the old behavior (using GOT
to address these functions).
An alternative would be adding a new "static-pie-start.S", and some
custom logic into Makefile to build rcrt1.o with it. And, restore
start.S to the state before static PIE change so crt1.o won't contain
PC-relative relocs against external symbols. But I can't see any
benefit of this alternative, so I'd just keep it simple.
Tested by building glibc with the following configurations:
1. Binutils trunk + GCC trunk. Static PIE enabled. All tests
passed.
2. Binutils 2.39 branch + GCC trunk. Static PIE disabled. Tests
related to ifunc failed (it's a known issue). All other tests
passed.
3. Binutils 2.39 branch + GCC 12 branch, cross compilation with
build-many-glibcs.py from x86_64-linux-gnu. Static PIE disabled.
Build succeeded.
2022-10-02 14:23:09 +00:00
|
|
|
#if ENABLE_STATIC_PIE
|
2022-09-24 07:45:34 +00:00
|
|
|
/* For static PIE, the GOT cannot be used in _start because the GOT entries are
|
LoongArch: Fix the condition to use PC-relative addressing in start.S
A start.o compiled from start.S with -DPIC and no -DSHARED is used by
both crt1.o and rcrt1.o. So the LoongArch static PIE patch
unintentionally introduced PC-relative addressing for main and
__libc_start_main into crt1.o.
While the latest Binutils (trunk, which will be released as 2.40)
supports the PC-relative relocs against an external function by creating
a PLT entry, the 2.39 release branch doesn't (and won't) support this.
An error is raised:
"PLT stub does not represent and symbol not defined."
So, we need the following changes:
1. Check if ld supports the PC-relative relocs against an external
function. If it's not supported, we deem static PIE unsupported.
2. Change start.S. If static PIE is supported, use PC-relative
addressing for main and __libc_start_main and rely on the linker to
create PLT entries. Otherwise, restore the old behavior (using GOT
to address these functions).
An alternative would be adding a new "static-pie-start.S", and some
custom logic into Makefile to build rcrt1.o with it. And, restore
start.S to the state before static PIE change so crt1.o won't contain
PC-relative relocs against external symbols. But I can't see any
benefit of this alternative, so I'd just keep it simple.
Tested by building glibc with the following configurations:
1. Binutils trunk + GCC trunk. Static PIE enabled. All tests
passed.
2. Binutils 2.39 branch + GCC trunk. Static PIE disabled. Tests
related to ifunc failed (it's a known issue). All other tests
passed.
3. Binutils 2.39 branch + GCC 12 branch, cross compilation with
build-many-glibcs.py from x86_64-linux-gnu. Static PIE disabled.
Build succeeded.
2022-10-02 14:23:09 +00:00
|
|
|
offsets instead of real addresses before __libc_start_main.
|
|
|
|
__libc_start_main and/or main may be not local, so we rely on the linker to
|
|
|
|
produce PLT entries for them. GNU ld >= 2.40 supports this. */
|
2022-09-24 07:45:34 +00:00
|
|
|
# define LA la.pcrel
|
|
|
|
#else
|
LoongArch: Fix the condition to use PC-relative addressing in start.S
A start.o compiled from start.S with -DPIC and no -DSHARED is used by
both crt1.o and rcrt1.o. So the LoongArch static PIE patch
unintentionally introduced PC-relative addressing for main and
__libc_start_main into crt1.o.
While the latest Binutils (trunk, which will be released as 2.40)
supports the PC-relative relocs against an external function by creating
a PLT entry, the 2.39 release branch doesn't (and won't) support this.
An error is raised:
"PLT stub does not represent and symbol not defined."
So, we need the following changes:
1. Check if ld supports the PC-relative relocs against an external
function. If it's not supported, we deem static PIE unsupported.
2. Change start.S. If static PIE is supported, use PC-relative
addressing for main and __libc_start_main and rely on the linker to
create PLT entries. Otherwise, restore the old behavior (using GOT
to address these functions).
An alternative would be adding a new "static-pie-start.S", and some
custom logic into Makefile to build rcrt1.o with it. And, restore
start.S to the state before static PIE change so crt1.o won't contain
PC-relative relocs against external symbols. But I can't see any
benefit of this alternative, so I'd just keep it simple.
Tested by building glibc with the following configurations:
1. Binutils trunk + GCC trunk. Static PIE enabled. All tests
passed.
2. Binutils 2.39 branch + GCC trunk. Static PIE disabled. Tests
related to ifunc failed (it's a known issue). All other tests
passed.
3. Binutils 2.39 branch + GCC 12 branch, cross compilation with
build-many-glibcs.py from x86_64-linux-gnu. Static PIE disabled.
Build succeeded.
2022-10-02 14:23:09 +00:00
|
|
|
/* Old GNU ld (< 2.40) cannot handle PC relative address against a non-local
|
|
|
|
function correctly. We deem these old linkers failing to support static PIE
|
|
|
|
and load the addresses from GOT. */
|
2022-09-24 07:45:34 +00:00
|
|
|
# define LA la.got
|
|
|
|
#endif
|
|
|
|
|
|
|
|
LA a0, t0, main
|
2022-07-19 01:20:46 +00:00
|
|
|
REG_L a1, sp, 0
|
|
|
|
ADDI a2, sp, SZREG
|
|
|
|
|
|
|
|
/* Adjust $sp for 16-aligned */
|
|
|
|
BSTRINS sp, zero, 3, 0
|
|
|
|
|
|
|
|
move a3, zero /* used to be init */
|
|
|
|
move a4, zero /* used to be fini */
|
|
|
|
or a6, sp, zero /* stack_end */
|
|
|
|
|
2022-09-24 07:45:34 +00:00
|
|
|
LA ra, t0, __libc_start_main
|
2022-07-19 01:20:46 +00:00
|
|
|
jirl ra, ra, 0
|
|
|
|
|
2022-09-24 07:45:34 +00:00
|
|
|
LA ra, t0, abort
|
2022-07-19 01:20:46 +00:00
|
|
|
jirl ra, ra, 0
|
|
|
|
END (ENTRY_POINT)
|