Re: vdso function descriptors (VDS64_HAS_DESCRIPTORS)?
On Mon, 2020-02-24 at 10:20 -0500, Joe Lawrence wrote: > On > > I don't remember why :-) I think I didn't want to mess with the OPD > > fixup in glibc back then. > > > > Does it make sense to just drop the unused VDS64_HAS_DESCRIPTORS code > then? I'd think so yes. Cheers, Ben.
Re: vdso function descriptors (VDS64_HAS_DESCRIPTORS)?
On 2/24/20 5:17 AM, Benjamin Herrenschmidt wrote: On Sat, 2020-02-22 at 18:07 -0600, Segher Boessenkool wrote: so I don't believe they are ever used by default -- in this case V_FUNCTION_BEGIN doesn't add to the .opd section with .name, .TOC base, etc. Manually setting VDS64_HAS_DESCRIPTORS results in a vdso64.so in which binutils tools like readelf properly report functions with symbol type FUNC instead of NOTYPE. Are there pieces of the build/etc toolchain unprepared for function descriptors? I'm just trying to figure out why the code defaults to unsetting them. Because direct calls are faster than indirect calls? Ben might have a fuller explanation, cc:ing him. I don't remember why :-) I think I didn't want to mess with the OPD fixup in glibc back then. Does it make sense to just drop the unused VDS64_HAS_DESCRIPTORS code then? -- Joe
Re: vdso function descriptors (VDS64_HAS_DESCRIPTORS)?
On Sat, 2020-02-22 at 18:07 -0600, Segher Boessenkool wrote: > > > > so I don't believe they are ever used by default -- in this case > > V_FUNCTION_BEGIN doesn't add to the .opd section with .name, .TOC base, > > etc. > > > > Manually setting VDS64_HAS_DESCRIPTORS results in a vdso64.so in which > > binutils tools like readelf properly report functions with symbol type > > FUNC instead of NOTYPE. > > > > Are there pieces of the build/etc toolchain unprepared for function > > descriptors? I'm just trying to figure out why the code defaults to > > unsetting them. > > Because direct calls are faster than indirect calls? Ben might have a > fuller explanation, cc:ing him. I don't remember why :-) I think I didn't want to mess with the OPD fixup in glibc back then. Ben.
Re: vdso function descriptors (VDS64_HAS_DESCRIPTORS)?
On Mon, Feb 17, 2020 at 11:08:52AM -0500, Joe Lawrence wrote: > I was wondering if there was history behind VDS64_HAS_DESCRIPTORS and in > what cases would one want to turn them on? (Note, I'm assuming they are > an implementation of Function Descriptors. [1]) It's from the very first patch implementing VDSOs for powerpc, which says: commit 86b67fe764e9e54443226a3a0b298f650588d6c5 Author: Benjamin Herrenschmidt Date: Fri Mar 4 17:33:32 2005 -0800 [PATCH] ppc64: Implement a vDSO and use it for signal trampoline [...] Note that the symbols exposed by the vDSO aren't "normal" function symbols, apps can't be expected to link against them directly, the vDSO's are both seen as if they were linked at 0 and the symbols just contain offsets to the various functions. This is done on purpose to avoid a relocation step (ppc64 functions normally have descriptors with abs addresses in them). When glibc uses those functions, it's expected to use it's own trampolines that know how to reach them. so already then this was unused code, presumably it was just used during development. > arch/powerpc/include/asm/vdso.h unsets the macro: > > /* Define if 64 bits VDSO has procedure descriptors */ > #undef VDS64_HAS_DESCRIPTORS > > so I don't believe they are ever used by default -- in this case > V_FUNCTION_BEGIN doesn't add to the .opd section with .name, .TOC base, > etc. > > Manually setting VDS64_HAS_DESCRIPTORS results in a vdso64.so in which > binutils tools like readelf properly report functions with symbol type > FUNC instead of NOTYPE. > > Are there pieces of the build/etc toolchain unprepared for function > descriptors? I'm just trying to figure out why the code defaults to > unsetting them. Because direct calls are faster than indirect calls? Ben might have a fuller explanation, cc:ing him. Segher
