Re: __syscall_error (was Re: [PATCH v4 13/15] ARC: Build Infrastructure)
On 4/2/20 1:50 AM, Florian Weimer via Libc-alpha wrote: >> What if you move it to GLIBC_PRIVATE? My concern isn't that it's exported >> from the shared library, it's that it's exported at a public version. > > I think it's preferable to duplicate __syscall_error in each shared > object that needs it. It avoids potential strange loops if the lazy > binding code itself ends up calling __syscall_error in an different > object (e.g., from the DSO that implements malloc). > > Maybe we can make this work as long as libc.so uses an internal call, > but it looks tricky. > > Alternatively, we can enable BIND_NOW unconditionally. This seems too big of a trade-off for a seeming small optimization. If you folks feel strongly, I can drop all of this __syscall_error dance. Just let me know what approach to take. ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: __syscall_error (was Re: [PATCH v4 13/15] ARC: Build Infrastructure)
* Joseph Myers: > What if you move it to GLIBC_PRIVATE? My concern isn't that it's exported > from the shared library, it's that it's exported at a public version. I think it's preferable to duplicate __syscall_error in each shared object that needs it. It avoids potential strange loops if the lazy binding code itself ends up calling __syscall_error in an different object (e.g., from the DSO that implements malloc). Maybe we can make this work as long as libc.so uses an internal call, but it looks tricky. Alternatively, we can enable BIND_NOW unconditionally. Thanks, Florian ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: __syscall_error (was Re: [PATCH v4 13/15] ARC: Build Infrastructure)
On 4/1/20 10:06 AM, Joseph Myers wrote: > >> If public Version is removed, I get errors like below: > > What if you move it to GLIBC_PRIVATE? My concern isn't that it's exported > from the shared library, it's that it's exported at a public version. > > A public version is only needed if there are references in code that might > be statically linked into user binaries that use shared libc. Which means > the symbol being used in some .o or .a file that gets linked into user > binaries in that case (crt*.o, lib*_nonshared.a). You can examine the > symbols used by such objects after building and installing glibc. Moving it to GLIBC_PRIVATE seems to work too. *Before* arc-linux-readelf -a lib/libc-2.31.9000.so | grep syscall_error 1671: 0001b4b418 FUNCGLOBAL DEFAULT 11 __syscall_error@@GLIBC_2.32 4686: 0001b4b418 FUNCLOCAL DEFAULT 11 __GI___syscall_error 6286: 0001b4b418 FUNCGLOBAL DEFAULT 11 __syscall_error arc-linux-readelf -a lib/librt-2.31.9000.so | grep syscall_error 8054 1f37 R_ARC_JMP_SLOT __syscall_error@GLIBC_2.32 + 0 31: 0 FUNCGLOBAL DEFAULT UND __syscall_error@GLIBC_2.32 (3) 198: 0 FUNCGLOBAL DEFAULT UND __syscall_error@@GLIBC_2. *Now* arc-linux-readelf -a lib/libc-2.31.9000.so | grep syscall_error 1671: 0001b4b418 FUNCGLOBAL DEFAULT 11 __syscall_error@@GLIBC_PRIVATE 4686: 0001b4b418 FUNCLOCAL DEFAULT 11 __GI___syscall_error 6286: 0001b4b418 FUNCGLOBAL DEFAULT 11 __syscall_error arc-linux-readelf -a lib/librt-2.31.9000.so | grep syscall_error 8068 2437 R_ARC_JMP_SLOT __syscall_error@GLIBC_PRIVATE + 0 36: 0 FUNCGLOBAL DEFAULT UND __syscall_error@GLIBC_PRIVATE (4) 206: 0 FUNCGLOBAL DEFAULT UND __syscall_error@@GLIBC_PR ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: __syscall_error (was Re: [PATCH v4 13/15] ARC: Build Infrastructure)
On 4/1/20 12:58 AM, Andreas Schwab wrote: > On Apr 01 2020, Vineet Gupta via Libc-alpha wrote: > >> Looking as RISCV code, they opencode __syscall_error for !IS_IN (libc) which >> I was >> hoping to avoid. > > But that is the right way to do it. The syscall error handler must be > local to the library, it cannot afford to go through the PLT to call a > function in a different library here. Still, It needs to fetch (and runtime prepare) the GOT entry anyways. The real point however is having the call avoids having to know/write asm code with the errno codegen ABI for TLS model etc Well its no big deal either way, not these days anyways (Given the ARC embedded background, I've histrionically been more sensitive to code size, but that boundary seems to be getting hazy/moot-point anyways...) ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: __syscall_error (was Re: [PATCH v4 13/15] ARC: Build Infrastructure)
On Wed, 1 Apr 2020, Vineet Gupta via Libc-alpha wrote: > > If there's an inline function referring to this in an installed header, we > > can consider whether that inline function *should* be referring to it. > > Similarly if there's a reference in crt*.o / lib*_nonshared.a / GCC static > > libraries, we can consider if that reference *should* be there or if the > > function in question should actually be calling some function from libc.so > > that does the syscall there. > > The assembler macros in syscall template for generating wrappers use > __syscall_error (sysdeps/unix/sysv/linux/arc/sysdep.h). That's an internal header. It might be included in code used in crt*.o / lib*_nonshared.a, but can't be included from any installed header, so can't result in references in inline functions from installed headers. > If public Version is removed, I get errors like below: What if you move it to GLIBC_PRIVATE? My concern isn't that it's exported from the shared library, it's that it's exported at a public version. A public version is only needed if there are references in code that might be statically linked into user binaries that use shared libc. Which means the symbol being used in some .o or .a file that gets linked into user binaries in that case (crt*.o, lib*_nonshared.a). You can examine the symbols used by such objects after building and installing glibc. -- Joseph S. Myers jos...@codesourcery.com ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: __syscall_error (was Re: [PATCH v4 13/15] ARC: Build Infrastructure)
On Apr 01 2020, Vineet Gupta via Libc-alpha wrote: > Looking as RISCV code, they opencode __syscall_error for !IS_IN (libc) which > I was > hoping to avoid. But that is the right way to do it. The syscall error handler must be local to the library, it cannot afford to go through the PLT to call a function in a different library here. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different." ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
