From: Stafford Horne <shorne@gmail.com>
To: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Cc: libc-alpha@sourceware.org, Openrisc <openrisc@lists.librecores.org>
Subject: Re: [PATCH v3 04/13] or1k: startup and dynamic linking code
Date: Tue, 21 Dec 2021 06:40:42 +0900 [thread overview]
Message-ID: <YcD4WgWHa1dXQIai@antec> (raw)
In-Reply-To: <bc0015db-fc33-6ce1-9f41-615676bc4266@linaro.org>
On Mon, Dec 20, 2021 at 04:45:21PM -0300, Adhemerval Zanella wrote:
>
>
> On 17/12/2021 20:03, Stafford Horne wrote:
> > On Thu, Dec 16, 2021 at 07:42:46AM -0300, Adhemerval Zanella wrote:
> >>
> >>
> >> On 10/12/2021 20:34, Stafford Horne via Libc-alpha wrote:
> >>> Code for C runtime startup and dynamic loading including PLT layout.
> >>
> >> Patch looks ok, although I comment much on ABI and assembly code. Some
> >> comments below.
> >>
> >>> ---
> >>> sysdeps/or1k/bits/link.h | 51 ++++++
> >>> sysdeps/or1k/dl-machine.h | 323 +++++++++++++++++++++++++++++++++++++
> >>> sysdeps/or1k/dl-start.S | 98 +++++++++++
> >>> sysdeps/or1k/ldsodefs.h | 40 +++++
> >>> sysdeps/or1k/sotruss-lib.c | 51 ++++++
> >>> sysdeps/or1k/start.S | 99 ++++++++++++
> >>> sysdeps/or1k/tst-audit.h | 24 +++
> >>> 7 files changed, 686 insertions(+)
> >>> create mode 100644 sysdeps/or1k/bits/link.h
> >>> create mode 100644 sysdeps/or1k/dl-machine.h
> >>> create mode 100644 sysdeps/or1k/dl-start.S
> >>> create mode 100644 sysdeps/or1k/ldsodefs.h
> >>> create mode 100644 sysdeps/or1k/sotruss-lib.c
> >>> create mode 100644 sysdeps/or1k/start.S
> >>> create mode 100644 sysdeps/or1k/tst-audit.h
> >>>
> >>> diff --git a/sysdeps/or1k/bits/link.h b/sysdeps/or1k/bits/link.h
> >>> new file mode 100644
> >>> index 0000000000..ad183c9625
> >>> --- /dev/null
> >>> +++ b/sysdeps/or1k/bits/link.h
> >>> @@ -0,0 +1,51 @@
> >>> +/* Declarations for dynamic linker interface. OpenRISC version.
> >>> + Copyright (C) 2021 Free Software Foundation, Inc.
> >>> + 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.
> >>> +
> >>> + 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
> >>> + License along with the GNU C Library. If not, see
> >>> + <https://www.gnu.org/licenses/>. */
> >>> +
> >>> +#ifndef _LINK_H
> >>> +# error "Never include <bits/link.h> directly; use <link.h> instead."
> >>> +#endif
> >>> +
> >>> +/* Registers for entry into PLT. */
> >>> +typedef struct La_or1k_regs
> >>> +{
> >>> + uint32_t lr_reg[31];
> >>> +} La_or1k_regs;
> >>> +
> >>
> >> So is the intent is to provide caller all the register, no only the caller-saved
> >> registers?
> >
> > As I see it...
> >
> > Shouldn't these usually be the argument registers used in la_pltenter to print
> > our the function call? i.e.
> >
> > print_enter (refcook, defcook, symname,
> > regs->lr_reg[0], regs->lr_reg[1], regs->lr_reg[2],
> > *flags);
> >
> > These registers get setup in sysdeps/{arch}/dl-trampoline.S by
> > _dl_runtime_profile, which then pass them to _dl_profile_fixup.
> >
> > The problem is openrisc doesn't implement _dl_runtime_profile so we haven't
> > defined what the registers are.
> >
> > I noticed the same for arc, csky, riscv.
> >
> > These are needed to be defined for sotruss, but I dont seem them being used.
> >
> > Is that correct?
>
> The register are really dependend of the function calling ABI of the architecture,
> if you check other architecture like x86 and powerpc you will see that La_i86_regs
> and La_ppc64_regs only saves the caller-saved ones. It is mainly because for
> PLT tracking, as done by audit modules, other register are not really useful
> (since they are just internal ones to the caller function).
I see, but isn't this register saving done in _dl_profile_resolve?
OpenRISC doesn't define _dl_profile_resolve.
I can change the definition of La_or1k_regs, but as I see it it is currently
not used other than building sotruss-lib and audit modules. But I don't see
how pltenter will be called without implementing _dl_profile_resolve.
> >
> >>> +/* Return values for calls from PLT. */
> >>> +typedef struct La_or1k_retval
> >>> +{
> >>> + uint32_t lrv_r3;
> >>> +} La_or1k_retval;
> >>> +
> >>> +__BEGIN_DECLS
> >>> +
> >>> +extern ElfW(Addr) la_or1k_gnu_pltenter (ElfW(Sym) *__sym, unsigned int __ndx,
> >>> + uintptr_t *__refcook,
> >>> + uintptr_t *__defcook,
> >>> + La_or1k_regs *__regs,
> >>> + unsigned int *__flags,
> >>> + const char *__symname,
> >>> + long int *__framesizep);
> >>> +extern unsigned int la_or1k_gnu_pltexit (ElfW(Sym) *__sym, unsigned int __ndx,
> >>> + uintptr_t *__refcook,
> >>> + uintptr_t *__defcook,
> >>> + const La_or1k_regs *__inregs,
> >>> + La_or1k_retval *__outregs,
> >>> + const char *__symname);
> >>> +
> >>> +__END_DECLS
> >>> diff --git a/sysdeps/or1k/dl-machine.h b/sysdeps/or1k/dl-machine.h
> >>> new file mode 100644
> >>> index 0000000000..d41554769e
> >>> --- /dev/null
> >>> +++ b/sysdeps/or1k/dl-machine.h
> >>> @@ -0,0 +1,323 @@
> >>> +/* Machine-dependent ELF dynamic relocation inline functions. OpenRISC version.
> >>> + Copyright (C) 2021 Free Software Foundation, Inc.
> >>> + 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.
> >>> +
> >>> + 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
> >>> + License along with the GNU C Library; if not, see
> >>> + <https://www.gnu.org/licenses/>. */
> >>> +
> >>> +#ifndef dl_machine_h
> >>> +#define dl_machine_h
> >>> +
> >>> +#define ELF_MACHINE_NAME "or1k"
> >>> +
> >>> +#include <sys/cdefs.h>
> >>> +#include <sys/param.h>
> >>> +#include <tls.h>
> >>> +#include <dl-irel.h>
> >>> +#include <dl-static-tls.h>
> >>> +#include <dl-machine-rel.h>
> >>> +
> >>> +/* Return nonzero iff ELF header is compatible with the running host. */
> >>> +static inline int __attribute__ ((unused))
> >>> +elf_machine_matches_host (const Elf32_Ehdr *ehdr)
> >>> +{
> >>> + return ehdr->e_machine == EM_OPENRISC;
> >>> +}
> >>> +
> >>> +static inline Elf32_Addr *
> >>> +or1k_get_got (void)
> >>> +{
> >>> + Elf32_Addr *got;
> >>> + register long int linkreg asm ("r9");
> >>
> >> Is the 'r9' a required register by the ABI to use on this assembly snippet?
> >> I am asking because local name 'registers' are only a hint to gcc, as we
> >> found recently [1], if you really need 'r9' you will probably need to use
> >> a global name resgister.
> >
> > The r9 is to avoid the snippet from clobbering r9. The result of l.jal will
> > update r9 (link register) we want to make sure that is what we used for %1.
> >
> > I think there were issues with other ways I tried.
>
> Should you add it the clobbered list instead?
>
> >
> > Let me look into it more.
> >
> >>> + asm ("l.jal 0x8\n"
> >>> + " l.movhi %0, gotpchi(_GLOBAL_OFFSET_TABLE_-4)\n"
> >>> + "l.ori %0, %0, gotpclo(_GLOBAL_OFFSET_TABLE_+0)\n"
> >>> + "l.add %0, %0, %1\n"
> >>> + : "=r" (got), "=r" (linkreg));
>
> With something like (unstested):
>
>
> static inline Elf32_Addr *
> or1k_get_got (void)
> {
> Elf32_Addr *got;
> asm ("l.jal 0x8\n"
> " l.movhi %0, gotpchi(_GLOBAL_OFFSET_TABLE_-4)\n"
> "l.ori %0, %0, gotpclo(_GLOBAL_OFFSET_TABLE_+0)\n"
> "l.add %0, %0, %1\n"
> : "=r" (got)
> :
> : "r9");
> }
Yes, this is what I ended up changing it to.
Is the indentation important here? I had it as:
static inline Elf32_Addr *
or1k_get_got (void)
{
Elf32_Addr *got;
asm ("l.jal 0x8\n"
" l.movhi %0, gotpchi(_GLOBAL_OFFSET_TABLE_-4)\n"
"l.ori %0, %0, gotpclo(_GLOBAL_OFFSET_TABLE_+0)\n"
"l.add %0, %0, r9\n"
: "=r" (got) : : "r9");
return got;
}
-Stafford
next prev parent reply other threads:[~2021-12-20 21:40 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-10 23:34 [PATCH v3 00/13] Glibc OpenRISC port Stafford Horne
2021-12-10 23:34 ` [PATCH v3 01/13] elf: Add reloc for OpenRISC Stafford Horne
2021-12-14 20:28 ` Adhemerval Zanella
2021-12-10 23:34 ` [PATCH v3 02/13] linux/syscalls: Add or1k_atomic syscall " Stafford Horne
2021-12-14 20:29 ` Adhemerval Zanella
2021-12-10 23:34 ` [PATCH v3 03/13] or1k: ABI Implementation Stafford Horne
2021-12-14 20:53 ` Adhemerval Zanella
2021-12-14 22:43 ` Joseph Myers
2021-12-15 1:15 ` Adhemerval Zanella
2021-12-15 23:33 ` Stafford Horne
2021-12-16 10:30 ` Adhemerval Zanella
2021-12-16 21:28 ` Stafford Horne
2021-12-10 23:34 ` [PATCH v3 04/13] or1k: startup and dynamic linking code Stafford Horne
2021-12-16 10:42 ` Adhemerval Zanella
2021-12-17 23:03 ` Stafford Horne
2021-12-20 19:45 ` Adhemerval Zanella
2021-12-20 21:40 ` Stafford Horne [this message]
2021-12-21 11:09 ` Adhemerval Zanella
2021-12-21 11:46 ` Stafford Horne
2021-12-10 23:34 ` [PATCH v3 05/13] or1k: Thread Local Storage support Stafford Horne
2021-12-16 11:35 ` Adhemerval Zanella
2021-12-16 12:37 ` Adhemerval Zanella
2021-12-16 19:26 ` Joseph Myers
2021-12-16 19:33 ` Adhemerval Zanella
2021-12-17 14:23 ` Stafford Horne
2021-12-10 23:34 ` [PATCH v3 06/13] or1k: Atomics and Locking primitives Stafford Horne
2021-12-16 12:52 ` Adhemerval Zanella
2021-12-16 19:43 ` Adhemerval Zanella
2021-12-17 15:03 ` Stafford Horne
2021-12-10 23:34 ` [PATCH v3 07/13] or1k: math soft float support Stafford Horne
2021-12-16 19:48 ` Adhemerval Zanella
2021-12-17 15:02 ` Stafford Horne
2021-12-10 23:34 ` [PATCH v3 08/13] or1k: Linux Syscall Interface Stafford Horne
2021-12-16 21:17 ` Adhemerval Zanella
2021-12-17 15:01 ` Stafford Horne
2021-12-17 17:41 ` Adhemerval Zanella
2021-12-20 11:53 ` Stafford Horne
2021-12-10 23:34 ` [PATCH v3 09/13] or1k: Linux ABI Stafford Horne
2021-12-21 13:41 ` Adhemerval Zanella
2021-12-21 14:54 ` Stafford Horne
2021-12-22 10:54 ` Stafford Horne
2021-12-10 23:34 ` [PATCH v3 10/13] or1k: ABI lists Stafford Horne
2021-12-22 20:20 ` Adhemerval Zanella
2021-12-23 8:36 ` Stafford Horne
2021-12-10 23:34 ` [PATCH v3 11/13] or1k: Build Infrastructure Stafford Horne
2021-12-22 21:03 ` Adhemerval Zanella
2021-12-23 7:32 ` Stafford Horne
2021-12-10 23:34 ` [PATCH v3 12/13] build-many-glibcs.py: add OpenRISC support Stafford Horne
2021-12-22 21:04 ` Adhemerval Zanella
2021-12-23 7:15 ` Stafford Horne
2021-12-10 23:34 ` [PATCH v3 13/13] Documentation for OpenRISC port Stafford Horne
2021-12-23 12:57 ` Adhemerval Zanella
2021-12-14 20:25 ` [PATCH v3 00/13] Glibc " Adhemerval Zanella
2021-12-15 1:19 ` Adhemerval Zanella
2021-12-15 5:34 ` Stafford Horne
2021-12-15 5:37 ` Stafford Horne
2021-12-23 15:46 ` Stafford Horne
2021-12-23 15:57 ` Andreas Schwab
2021-12-23 21:26 ` Stafford Horne
2021-12-25 7:24 ` Stafford Horne
2021-12-25 22:44 ` Stafford Horne
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YcD4WgWHa1dXQIai@antec \
--to=shorne@gmail.com \
--cc=adhemerval.zanella@linaro.org \
--cc=libc-alpha@sourceware.org \
--cc=openrisc@lists.librecores.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).