Re: [PATCH v3 1/2] scripts: Add "|" operator support to glibcpp's parsing
* Shahab Vahedi:
> From the tests point of view, this is a necessary step for another
> patch [1] and allows parsing macros such as "#define A | B". Without
> it, a few tests [2] choke when the other patch [1] is applied:
>
> /src/glibc/scripts/../elf/elf.h:4167: error: uninterpretable macro
> token sequence: ( EF_ARC_MACH_MSK | EF_ARC_OSABI_MSK )
> Traceback (most recent call last):
> File "/src/glibc/elf/tst-glibcelf.py", line 23, in
> import glibcelf
> File "/src/glibc/scripts/glibcelf.py", line 226, in
> _elf_h = _parse_elf_h()
>^^
> File "/src/glibc/scripts/glibcelf.py", line 223, in _parse_elf_h
> raise IOError('parse error in elf.h')
> OSError: parse error in elf.h
>
> [1] ARC: update definitions in elf/elf.h
> https://sourceware.org/pipermail/libc-alpha/2022-November/143503.html
>
> [2]
> tst-glibcelf, tst-relro-ldso, and tst-relro-libc
>
> Signed-off-by: Shahab Vahedi
This okay and can go in separately, thanks.
Reviewed-by: Florian Weimer
Florian
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH] support: user more portable atomic wrappers
* Vineet Gupta: > I agree that gcc atomics should be baseline. I would still propose to > carry this patch as it makes code less verbose if nothing else and the > wrappers are part of glibc already. The advantage of the GCC built-ins is that they have easy-to-find documentation. Our wrapper macros are in the same file as the legacy atomics that no longer should be used. They are also not easy to use correctly (e.g., there is no support for access to single bytes, but the code will still compile on some architectures). The GCC built-ins have other problems, of course. For example, one might accidentally introduce a dependency on libatomic (leading to a link failure later). But I think these issues are less severe. Thanks, Florian -- Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH] support: user more portable atomic wrappers
* Vineet Gupta via Libc-alpha: > This came up in a nascent arc64 port, lacking gcc atomics for now Can you please change the GCC port to provide atomics instead? It does not make sense to maintain those atomics in many projects separately. Thanks, Florian -- Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v2] elf: Change TLS static surplus default back to 1664
* Vineet Gupta via Libc-alpha: > Hi Florian, > > On 7/17/20 4:41 AM, Florian Weimer via Libc-alpha wrote: >> Make the computation in elf/dl-tls.c more transparent, and add >> an explicit test for the historic value. >> >> --- >> elf/Makefile | 4 +++- >> elf/dl-tls.c | 37 ++--- >> elf/tst-tls-surplus.c | 42 ++ >> 3 files changed, 75 insertions(+), 8 deletions(-) > > On ARC, tst-tls-surplus passes, but it seems there's still some static TLS > shenanigans. > > FAIL: elf/tst-tls-ie > FAIL: elf/tst-tls-ie-dlmopen > > $ cat elf/tst-tls-ie.out > > maintls[1000]: 0x20026f80 .. 0x20027368 > var0[480]: 0x2093c648 .. 0x2093c828 global-dynamic > var1[120]: 0x2093cc40 .. 0x2093ccb8 global-dynamic > var2[24]: 0x2093d0d0 .. 0x2093d0e8 global-dynamic > var3[16]: 0x2093d500 .. 0x2093d510 global-dynamic > error: xdlfcn.c:29: error: dlopen: > glibc-2.31.9000-730-ge9422236a2dd4/build/elf/tst-tls-ie-mod4.so: cannot > allocate > memory in static TLS block > > cat elf/tst-tls-ie-dlmopen.out > maintls[1000]: 0x20026f80 .. 0x20027368 > var0[480]: 0x2093c648 .. 0x2093c828 global-dynamic > var1[120]: 0x2093d3d8 .. 0x2093d450 global-dynamic > var2[24]: 0x2093e000 .. 0x2093e018 global-dynamic > var3[16]: 0x2093ebc8 .. 0x2093ebd8 global-dynamic > error: xdlmopen.c:28: error: dlmopen: > glibc-2.31.9000-730-ge9422236a2dd4/build/elf/tst-tls-ie-mod6.so: cannot > allocate > memory in static TLS block I looked at the binaries, but I do not see anything obviously wrong. I think you need to single-step through the allocations to see where they fail, sorry. Thanks, Florian ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH] Fix tst-libc_dlvsym{, -static} on ARC: don't check _sys_{err, sig}list
* Vineet Gupta via Libc-alpha: > diff --git a/elf/tst-libc_dlvsym.h b/elf/tst-libc_dlvsym.h > index 6b132dd7c3e4..7eda47207824 100644 > --- a/elf/tst-libc_dlvsym.h > +++ b/elf/tst-libc_dlvsym.h > @@ -117,8 +117,6 @@ compare_vsyms (void) > obtain an explicit handle for libc.so. */ >void *libc_handle = xdlopen (LIBC_SO, RTLD_LAZY | RTLD_NOLOAD); > > - compare_vsyms_1 (libc_handle, "_sys_errlist"); > - compare_vsyms_1 (libc_handle, "_sys_siglist"); >compare_vsyms_1 (libc_handle, "quick_exit"); > >xdlclose (libc_handle); Please use TEST_COMPAT, as in malloc/tst-mallocstate.c. Thanks, Florian ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: ARC testsuite regressions (was Re: [PATCH v7.2 07/13] ARC: Linux Syscall Interface)
* Vineet Gupta: > On 7/10/20 10:02 AM, Florian Weimer via Libc-alpha wrote: >> * Vineet Gupta via Libc-alpha: >> >>> From scratch meaning glibc alone or the whole toolchain. I used >>> buildroot and glibc-dirclean to nuke entire glibc but gcc was not >>> rebuilt. I can try that too. >> >> No, rebuilding glibc from scratch should be fine. > > Right, I clean built the entire toolchain and that didn't help - but turned > out to > be sane thing anyways as installed headers seems were not rebuilt/installed > and I > needed the signum.h -> signum-arch.h fixup in vfork.S > > >>> Some of the failed tests have prints about static TLS block ... so I'm >>> wondering if they could be related ? >>> >>> | $ cat dlfcn/tststatic.out >>> | .../build/libc.so.6: cannot allocate memory in static TLS block >> >> This suggests to me that the static initialization code does not produce >> sufficient alignment for the TCB, given the 32-byte alignment required >> by the rseq area. >> >> You could try and see what happens if you change >> sysdeps/arc/nptl/pthreaddef.h to this: >> >> /* Alignment requirement for TCB. */ >> #define TCB_ALIGNMENT 32 >> >> If that helps, we have more of a generic issue here. 8-/ > > Bingo, that fixes all the dlfcn/* failures (full testsuite still running) > > PASS: dlfcn/tststatic > PASS: dlfcn/tststatic2 > PASS: dlfcn/tststatic3 > PASS: dlfcn/tststatic4 > PASS: dlfcn/tststatic5 > > So is that the fix or more is needed ? I have just posted an architecture-independent change here: <https://sourceware.org/pipermail/libc-alpha/2020-July/116143.html> I had forgotten about the similar code for static dlopen when I made the adjustment in elf/dl-tls.c. I think we need to clean this up eventually, it's fairly broken unfortunately. But the patch I posted should paper over this problem as far libc.so is concerned (like the previous patch for dynamic TLS). Would you mind reverting the TCB_ALIGNMENT change and test this patch? Thanks, Florian ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: ARC testsuite regressions (was Re: [PATCH v7.2 07/13] ARC: Linux Syscall Interface)
* Alistair Francis: > On Fri, Jul 10, 2020 at 8:55 AM Vineet Gupta via Libc-alpha > wrote: >> >> On 7/10/20 2:28 AM, Florian Weimer via Libc-alpha wrote: >> > * Alistair Francis via Libc-alpha: >> > >> >> On Thu, Jul 9, 2020 at 2:36 PM Vineet Gupta via Libc-alpha >> >> wrote: >> >>> >> >>> On 7/9/20 2:13 PM, Vineet Gupta via Libc-alpha wrote: >> >>>>> Rebased ARC port on master and fired a build-many-glibcs now >> >>>>> (expect some >> >>>>> abilist updates). Will do a full testsuite run >> >>>> >> >>>> No regressions in sysvipc tests ! >> >>> >> >>> But quite a few regressions. Baseline is ARC port off of upstream >> >>> 81b1c8cbb5b4 >> >>> "(hurd: Simplify usleep timeout computation)" and failures below seen in >> >>> ARC port >> >>> off of today's master ffd178c651b8 "(sysv: linux: Add 64-bit time_t >> >>> variant for >> >>> shmctl)" >> >>> >> >>> FAIL: dlfcn/tststatic >> >>> FAIL: dlfcn/tststatic2 >> >>> FAIL: dlfcn/tststatic3 >> >>> FAIL: dlfcn/tststatic4 >> >>> FAIL: dlfcn/tststatic5 >> >>> FAIL: elf/tst-libc_dlvsym >> >>> FAIL: elf/tst-libc_dlvsym-static >> >>> FAIL: elf/tst-single_threaded-static-dlopen >> >>> FAIL: elf/tst-tls9-static >> >> >> >> I see the same recent-ish regressions for RV32. >> > >> > Did you rebuild from scratch? After the libc.so/ld.so ABI changes that >> > went in recently, it could be the result of incomplete make >> > dependencies. >> >> From scratch meaning glibc alone or the whole toolchain. I used buildroot and >> glibc-dirclean to nuke entire glibc but gcc was not rebuilt. I can try that >> too. > > That's the same with me. The toolchain wasn't rebuilt but glibc was > built from a clean directory. I am rebuilding now with a rebuilt > toolchain. > >> >> Some of the failed tests have prints about static TLS block ... so I'm >> wondering >> if they could be related ? > > I see the same messages. > >> >> | $ cat dlfcn/tststatic.out >> | .../build/libc.so.6: cannot allocate memory in static TLS block > > That's what I see as well. Sorry, my fault. I posted a patch that should fix static dlopen: <https://sourceware.org/pipermail/libc-alpha/2020-July/116143.html> Would you mind testing it? Thanks, Florian ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: ARC testsuite regressions (was Re: [PATCH v7.2 07/13] ARC: Linux Syscall Interface)
* Vineet Gupta via Libc-alpha: > From scratch meaning glibc alone or the whole toolchain. I used > buildroot and glibc-dirclean to nuke entire glibc but gcc was not > rebuilt. I can try that too. No, rebuilding glibc from scratch should be fine. > Some of the failed tests have prints about static TLS block ... so I'm > wondering if they could be related ? > > | $ cat dlfcn/tststatic.out > | .../build/libc.so.6: cannot allocate memory in static TLS block This suggests to me that the static initialization code does not produce sufficient alignment for the TCB, given the 32-byte alignment required by the rseq area. You could try and see what happens if you change sysdeps/arc/nptl/pthreaddef.h to this: /* Alignment requirement for TCB. */ #define TCB_ALIGNMENT 32 If that helps, we have more of a generic issue here. 8-/ The problem is that the TLS memory allocator does not add alignment padding on its own. This could meet additional alignment requirements if there is just one thread yet when higher-aligned TLS is loaded. > Also while we figure this out, does this prevent ARC port from being > committed. I don't think so. We just have to make sure that it does not block the release, i.e. resolve this during the next week or two. Do you think that would that be possible? Thanks, Florian ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: ARC testsuite regressions (was Re: [PATCH v7.2 07/13] ARC: Linux Syscall Interface)
* Alistair Francis via Libc-alpha: > On Thu, Jul 9, 2020 at 2:36 PM Vineet Gupta via Libc-alpha > wrote: >> >> On 7/9/20 2:13 PM, Vineet Gupta via Libc-alpha wrote: >> >> Rebased ARC port on master and fired a build-many-glibcs now >> >> (expect some >> >> abilist updates). Will do a full testsuite run >> > >> > No regressions in sysvipc tests ! >> >> But quite a few regressions. Baseline is ARC port off of upstream >> 81b1c8cbb5b4 >> "(hurd: Simplify usleep timeout computation)" and failures below seen in ARC >> port >> off of today's master ffd178c651b8 "(sysv: linux: Add 64-bit time_t variant >> for >> shmctl)" >> >> FAIL: dlfcn/tststatic >> FAIL: dlfcn/tststatic2 >> FAIL: dlfcn/tststatic3 >> FAIL: dlfcn/tststatic4 >> FAIL: dlfcn/tststatic5 >> FAIL: elf/tst-libc_dlvsym >> FAIL: elf/tst-libc_dlvsym-static >> FAIL: elf/tst-single_threaded-static-dlopen >> FAIL: elf/tst-tls9-static > > I see the same recent-ish regressions for RV32. Did you rebuild from scratch? After the libc.so/ld.so ABI changes that went in recently, it could be the result of incomplete make dependencies. Thanks, Florian ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 3/5] iee754: prvoide gcc builtins based generic fma functions
The commit subject contains a typo (“prvoide”). ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 2/5] iee754: prvoide gcc builtins based generic sqrt functions
There's a typo in commit subject: “prvoide”. ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v3] Make any 32-bit time based syscalls unavailable for TIMESIZE==64
* Vineet Gupta via Libc-alpha: > On 4/13/20 2:12 PM, Vineet Gupta via Libc-alpha wrote: >> On 4/6/20 11:54 AM, Vineet Gupta wrote: >>> On 3/31/20 2:47 PM, Vineet Gupta via Libc-alpha wrote: From: Vineet Gupta via Libc-alpha An older asm-generic syscall ABI may have kernel provide 32-bit time syscalls, so undef them to not mix 32/64 in 64-bit time regime. Signed-off-by: Vineet Gupta >>> >>> ping ! >> >> ping ^2 ! > > If this is not suitable for common code, I'd still like to add this > as part of ARC port to safe guard against future snafus. Have you tried to add the #undefs to fixup-asm-unistd.h? See sysdeps/unix/sysv/linux/arm/fixup-asm-unistd.h for an example. I have not tried if #undefs work there, but they should. If not, we can fix that. ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v5 11/14] ARC: Update syscall-names.list for ARC specific syscalls
* Vineet Gupta via Libc-alpha: > On 4/17/20 4:05 PM, Joseph Myers wrote: >> This patch is OK. > > So when the rest of port is ready, this will be part of main commit ? I think this can go in today. ___ 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: [PATCH] provide y2038 safe socket constants
* Vineet Gupta: > On 3/31/20 12:34 PM, Florian Weimer wrote: >> What about the parallel changes to the sysdeps overrides? I would> expect >> changes for hppa, mips, powerpc. (Not sure about the alpha >> situation.) > > This patch fixes the existing/future asm-generic ABI enabled arches > and the ones you refer to are not. So IMHO that would be a separate > patch if at all. Ahh, I think the commit message could make this clearer (although it it's somewhat implied). The commit message also lacks a period at the end. But is the conditional correct for x32? It has to be keep using the old macro definitions. ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH] provide y2038 safe socket constants
* Vineet Gupta via Libc-alpha: > These will be used by upcoming RV32 and ARC ports and any future ports > > Signed-off-by: Vineet Gupta > --- > sysdeps/unix/sysv/linux/bits/socket-constants.h | 14 -- > 1 file changed, 12 insertions(+), 2 deletions(-) > > diff --git a/sysdeps/unix/sysv/linux/bits/socket-constants.h > b/sysdeps/unix/sysv/linux/bits/socket-constants.h > index 9dcc19cd5380..8a48ae7d0ca2 100644 > --- a/sysdeps/unix/sysv/linux/bits/socket-constants.h > +++ b/sysdeps/unix/sysv/linux/bits/socket-constants.h What about the parallel changes to the sysdeps overrides? I would expect changes for hppa, mips, powerpc. (Not sure about the alpha situation.) ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v3 12/17] ARC: ABI lists
* Vineet Gupta: > On 3/7/20 7:20 AM, Florian Weimer wrote: >> * Vineet Gupta: >> >>> +GLIBC_2.32 sysctl F >> >> This looks like a mistake, given that ARC doesn't even have the sysctl >> system call. >> >> I think the current way of suppressing that involves creating an empty >> sysctl.mk file, as in sysdeps/unix/sysv/linux/x86_64/x32/sysctl.mk. >> (Unfortunately, the ports added after x32 forgot to do that because >> the in-tree default is wrong.) > > For now I've added an empty file and in a later sweep we can remove all the > empty > ones as you suggest below. Thx for taking a look. Thanks. I posted my removal patch as well: <https://sourceware.org/pipermail/libc-alpha/2020-March/111739.html> ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v3 12/17] ARC: ABI lists
* Vineet Gupta: > +GLIBC_2.32 sysctl F This looks like a mistake, given that ARC doesn't even have the sysctl system call. I think the current way of suppressing that involves creating an empty sysctl.mk file, as in sysdeps/unix/sysv/linux/x86_64/x32/sysctl.mk. (Unfortunately, the ports added after x32 forgot to do that because the in-tree default is wrong.) Alternatively, we can remove the header first and turn sysctl into a compat symbol, so that the symbol will be gone without further action on your part. ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: ELF_INITFINI for ARC (was Re: [PATCH] Introduce and ELF_INITFINI for all architectures)
* Vineet Gupta:
> It seems that commit also removed init_array from
> sysdeps/{riscv,csky}/Implies - so newer arches. I suppose I need to do
> that for ARC as well - but could you please explain (or point to
> documentation) which explains how this the Implies stuff works.
You are very lucky. The mechanism is explained in the section Porting
the GNU C Library in the manual:
It's one of the few aspects of our build systems that's documented.
However, in commit f4349837d93b4dfe9ba09791e280ee2d6c99919f ("Introduce
and ELF_INITFINI for all architectures") I replaced the
use of the implies mechanism with a new header file, .
This allows us to control the default for new targets in a more explicit
way. Previously, new ports had to include initarray explicitly, and we
know from past experience (the lack of removal of the sysctl function
comes to my mind) that this does not work.
>> But I'm no longer sure if RISC-V is actually an !ELF_INITFINI
>> architecture.
>
> And an arch is !ELF_INITFINI if it supports initarray ?
Not necessarily. glibc always supports DT_INITARRAY for all targets,
but on some targets, it is necessary to honor DT_INIT/DT_FINI for legacy
binaries at least. (I hope no targets are left where binutils produces
DT_INIT for regular ELF constructors, but I haven't checked.)
> I did switch ARC gcc [1] / binutils [2]to initarray last year
>
> [1]
> http://lists.infradead.org/pipermail/linux-snps-arc/2019-January/005318.html
> [2]
> http://lists.infradead.org/pipermail/linux-snps-arc/2019-February/005388.html
I haven't followed the ARC contribution process closely, sorry. Do you
plan to contribute the port with a GLIBC_2.32 ABI baseline, or do you
want to support older binaries for an earlier non-upstream port,
backdating the baseline?
This matters because in the GLIBC_2.32 case, old binaries will not work
anyway, so we may as well require that they are rebuilt without
DT_INIT/DT_FINI. In this case, the glibc master defaults should work.
If you want to support old binaries (which use older symbol versions
such as GLIBC_2.17), it may make sense to keep DT_INIT/DT_FINI support
as well. To achieve this, you need to add an header
file with
/* Enable DT_INIT/DT_FINI support. */
#define ELF_INITFINI 1
and keep the crti.S and crtn.S files you already have.
Thanks,
Florian
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH] Force 64-bit time based syscalls for TIMESIZE==64 on 32-bit arches
* Vineet Gupta: > +/* Override syscalls for asm-generic ABIs with 64-bit time. */ > +#if __WORDSIZE == 32 && __TIMESIZE == 64 > + > +# undef __NR_futex > +# define __NR_futex __NR_futex_time64 > + > +# undef __NR_rt_sigtimedwait > +# define __NR_rt_sigtimedwait __NR_rt_sigtimedwait_time64 I'm not totally unsympathetic to this in principle, but I think if we start messing more with the system call numbers in this way, we should move away from the __NR_ prefixes and use our own constant names. Otherwise, the results could be very confusing, especially if there are exceptions to this exception and we need the original system call number after all. Thanks, Florian ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH] asm-generic ABI: Allow statx syscall despite fstatat64, fstat64
* Vineet Gupta: > On 2/24/20 11:13 AM, Florian Weimer wrote: >> * Vineet Gupta: >> >>> On 2/24/20 10:39 AM, Florian Weimer wrote: >>>>> +# undef STAT64_IS_NOT_KERNEL_STAT64 >>>> Sorry, I think that going forward, we prefer that such macros are always >>>> defined, with values 0 or 1 as appropriate. >>> >>> And that means we also need to additionally define this to 0 in all >>> ports which don't end up including the generic header ? >> >> Yes, or move the definition into its own header, with the default for >> *future* architectures (not the majority of the current architectures) >> in the header in the sysdeps/unix/sysv/linux directory. > > Adding a new file would seem too kludgy. I think it's the preferred approach. Here's a recent discussion that looks at a few options in this space: <https://sourceware.org/ml/libc-alpha/2019-10/msg00030.html> > Adding it to existing arch headers is still OK but then one needs to > know what exact syscall ABI each arch has as even asm-generic ones > differ depending on when the linux port was merged. And the only way > to know that is to do a build for each arch or is there some > documentation one could refer to. In your case, the build should fail somewhere if there is a mismatch and the #define is incorrect for a particular architecture. In this case, you can keep running build-many-glibcs.py and making tweaks to the failing architectures until all failures are gone. Thanks, Florian ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH] asm-generic ABI: Allow statx syscall despite fstatat64, fstat64
* Vineet Gupta: > On 2/24/20 10:39 AM, Florian Weimer wrote: >>> +# undef STAT64_IS_NOT_KERNEL_STAT64 >> >> Sorry, I think that going forward, we prefer that such macros are always >> defined, with values 0 or 1 as appropriate. > > And that means we also need to additionally define this to 0 in all > ports which don't end up including the generic header ? Yes, or move the definition into its own header, with the default for *future* architectures (not the majority of the current architectures) in the header in the sysdeps/unix/sysv/linux directory. Thanks, Florian ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH] asm-generic ABI: Allow statx syscall despite fstatat64, fstat64
* Vineet Gupta: > +/* Ports define to 1 when glibc struct stat64 is not compatible with > + kernel stat64. This forces use of statx syscall (and explicit > interworking) > + even when fstat64 syscall is available. For asm-generic ABI this happened > + with switch to 64-bit time_t. */ > + > +# undef STAT64_IS_NOT_KERNEL_STAT64 Sorry, I think that going forward, we prefer that such macros are always defined, with values 0 or 1 as appropriate. Thanks, Florian ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [uclibc-ng-devel] stdio fudging errno ?
* Vineet Gupta:
> Here's a simple test case which shows the problem:
>
> #define _GNU_SOURCE
> #include
> #include
> #include
>
> void main(void)
> {
> const char *this_func = "finite";
> char *test_name;
>
> errno = 0;
> if (asprintf (&test_name, "%s (%s)", this_func, "my-str") == -1)
> abort ();
>
> printf("%d\n", errno); // <-- prints 11
> }
>
> The errno unconditionally being set to EAGAIN seems to have been
> introduced in commit 568ceebf6adfc58c64a95133311268db6 ("Fix
> infinite loop when fopencookie custom write returns 0 on error")
> bakc in 2016.
For functions specified by standards, successful calls can alter errno
unless specified otherwise. asprintf is not a standardized function,
but it is reasonable to expect that a similar rule applies.
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH] posix/tst-getaddrinfo4: Consider EAI_NODATA as an expected result
* Alexey Brodkin: > Hi Florian, > >> -Original Message----- >> From: Florian Weimer >> Sent: Thursday, April 18, 2019 3:08 PM >> To: Alexey Brodkin >> Cc: libc-al...@sourceware.org; linux-snps-arc@lists.infradead.org >> Subject: Re: [PATCH] posix/tst-getaddrinfo4: Consider EAI_NODATA as an >> expected result >> >> * Alexey Brodkin: >> >> > Some proxy DNS servers might not resolve IPv6 names to addresses. >> > Instead they reply with NOERROR while passing no real data. >> > That combination of NOERROR and EAI_NODATA happen because the DNS >> > server has a recored for requested name (example.net in our case) >> > but that record is not of type which was requested. >> >> I think this invalidates the test to a large degree. I don't think this >> is a valid test environment. You need to fix it. > > I think more interesting would be to figure out if behavior that I see > is valid or not and then decide which test is representative. The test was added for this bug: getaddrinfo returns EAI_SYSTEM instead of EAI_NONAME when the network is down <https://sourceware.org/bugzilla/show_bug.cgi?id=15339> So I think the return code from getaddrinfo matters here. We could switch to a namespace with disabled networking; this way, the test would perhaps be more reliable. I also think the test is wrong. EAI_NONAME indicates (negative) success, something that should not happen if networking is disabled. Thanks, Florian ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH] posix/tst-getaddrinfo4: Consider EAI_NODATA as an expected result
* Alexey Brodkin: > Some proxy DNS servers might not resolve IPv6 names to addresses. > Instead they reply with NOERROR while passing no real data. > That combination of NOERROR and EAI_NODATA happen because the DNS > server has a recored for requested name (example.net in our case) > but that record is not of type which was requested. I think this invalidates the test to a large degree. I don't think this is a valid test environment. You need to fix it. Thanks, Florian ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH] testsuite fix: timezone: failing due to permissions in cross testing
* Joseph Myers: > On Tue, 18 Dec 2018, Florian Weimer wrote: > >> There are also some xtests that require root privileges, such as >> nptl/tst-setuid1. Building and testing as root is supported (but > > That looks like it ought to become a test using user namespaces (and so > not an xtest). Can an unprivileged user namespace really be used to get a working setuid? The setup code in support_become_root/setup_uid_gid_mapping does not provide that. Thanks, Florian ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: ARC vs. generic sigaction (was Re: [PATCH 08/21] ARC: Linux Syscall Interface)
* Vineet Gupta: > On 12/20/18 4:40 AM, Florian Weimer wrote: >> * Adhemerval Zanella: >> >>> The only advantage of using a larger sigset_t from glibc standpoint is if >>> kernel ever change it maximum number of supported signals it would not be >>> a ABI change (it would be if glibc provided sigset_t need to be extended). >> It's not just the kernel. We might want to restore additional state in >> sigsetjmp, and historically, the excess signal space in sigset_t has >> provided a way to do that even if there is no other space left in the >> jump buffer. > > And that additional state is architectural state (more FPU regs etc > etc) or something libc generic. On both counts, that doesn't sound > like a clean interface design ! Sure, setjmp/longjmp is quite horrible as an interface, considering that register files do evolve. But it's what we have in C, and it's good to have at least some extension space there (but it could be expressed in a better way, definitely). Thanks, Florian ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: ARC vs. generic sigaction (was Re: [PATCH 08/21] ARC: Linux Syscall Interface)
* Adhemerval Zanella: > The only advantage of using a larger sigset_t from glibc standpoint is if > kernel ever change it maximum number of supported signals it would not be > a ABI change (it would be if glibc provided sigset_t need to be extended). It's not just the kernel. We might want to restore additional state in sigsetjmp, and historically, the excess signal space in sigset_t has provided a way to do that even if there is no other space left in the jump buffer. Thanks, Florian ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 12/21] ARC: Update syscall-names.list for ARC specific syscalls
* Vineet Gupta: > On 12/18/18 1:26 PM, Florian Weimer wrote: >> This should come in with a sync with a released upstream kernel. Will >> the port be in Linux 4.20? > > linux port was upstreamed in 2013 in v3.9 Ah, right, we add system calls to the lists only for our ports. Thanks, Florian ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 14/21] ARC: Enable __start as entry point vs. canonical _start
* Vineet Gupta: > ARC linker scripts have defined __start as entry point so to not break > ABI for uClibc et al we allow __start for glibc as well I think this change and the test suite fixes should be folded into the initial addition of these files. Or is there a reason for not doing this? Thanks, Florian ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 12/21] ARC: Update syscall-names.list for ARC specific syscalls
* Vineet Gupta: > diff --git a/sysdeps/unix/sysv/linux/syscall-names.list > b/sysdeps/unix/sysv/linux/syscall-names.list > index f88001c9c38d..62862010600f 100644 > --- a/sysdeps/unix/sysv/linux/syscall-names.list > +++ b/sysdeps/unix/sysv/linux/syscall-names.list > @@ -42,6 +42,9 @@ adjtimex > afs_syscall > alarm > alloc_hugepages > +arc_gettls > +arc_settls > +arc_usr_cmpxchg > arch_prctl > arm_fadvise64_64 > arm_sync_file_range This should come in with a sync with a released upstream kernel. Will the port be in Linux 4.20? Thanks, Florian ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH] testsuite fix: timezone: failing due to permissions in cross testing
* Joseph Myers: > On Mon, 17 Dec 2018, Vineet Gupta wrote: > >> timezone test driver "zic" creates testdata directory wuth umask 755, so >> only root owner/group has write permissions. However the buildroot > > root should not be involved in running tests at all; all tests should run > as a normal user, the same one that owns the build directory, and thus all > files and directories in the build directory should be owned by that user. > (Some tests use user namespaces to test functionality that requires root, > but that's root inside a namespace, not the real user root.) There are also some xtests that require root privileges, such as nptl/tst-setuid1. Building and testing as root is supported (but obviously not recommended unless you use a throwaway machine). Thanks, Florian ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH] tst-tzset: raise timeout to 10 seconds
On 07/30/2018 06:07 PM, Andreas Schwab wrote: On Jul 30 2018, Joseph Myers wrote: On Mon, 30 Jul 2018, Alexey Brodkin wrote: diff --git a/timezone/tst-tzset.c b/timezone/tst-tzset.c index 27f986b56dab..534f7acdf75f 100644 --- a/timezone/tst-tzset.c +++ b/timezone/tst-tzset.c @@ -25,7 +25,7 @@ #include #include -#define TIMEOUT 5 +#define TIMEOUT 10 The timeout was set to 5 in commit 112f28e88c4ea5afbd6050e71416a23db11e4adc to increase it from a default 2 seconds. That was before the default timeout was changed to 20 seconds in commit a28605b22946c708f0a5c4f06307e1a17650ced8. In such cases I think we should remove the timeout setting - explicit timeouts less than the default are only appropriate where there is a strong reason to want to *decrease* the default timeout. There are a lot of tests that set TIMEOUT to less than 20. We should fix all of them. Thanks, Florian ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [RFC 4/6] ARC: Initial port to glibc
On 06/27/2017 01:55 PM, Vineet Gupta wrote: > On 06/27/2017 02:29 PM, Florian Weimer wrote: >> On 06/27/2017 10:00 AM, Vineet Gupta wrote: >>> diff --git a/sysdeps/unix/sysv/linux/arc/shlib-versions >>> b/sysdeps/unix/sysv/linux/arc/shlib-versions >>> new file mode 100644 >>> index ..c4d5d029812d >>> --- /dev/null >>> +++ b/sysdeps/unix/sysv/linux/arc/shlib-versions >>> @@ -0,0 +1,2 @@ >>> +DEFAULT GLIBC_2.21 >>> +ld=ld-linux.so.2 >> >> Is there a reason why you set the ABI baseline to GLIBC_2.21? Why not >> GLBIC_2.26? > > No real reason, perhaps this is the version where we started off of. > I'll change this - and other places to 2.26 ! Great. Note that this will cause problems with some tests which exercise compatibility symbols. I still want to contribute the build system changes required to support them, but I probably won't be able to make the July 1st deadline. (Realistically, I'd need a port which can build with build-many-glibcs.py for that anyway.) Thanks, Florian ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [RFC 0/6] glibc port to ARC architecture
On 06/27/2017 10:00 AM, Vineet Gupta wrote: > This is a Request for comments for glibc port to ARC architecture. > http://www.synopsys.com/IP/ProcessorIP/ARCProcessors/Pages/default.aspx > > The Linux kernel, uClibc, buildroot have been upstream for quite some time. Is it possible to build the new port with scripts/build-many-glibcs.py? Thanks, Florian ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [RFC 4/6] ARC: Initial port to glibc
On 06/27/2017 10:00 AM, Vineet Gupta wrote: > diff --git a/sysdeps/unix/sysv/linux/arc/shlib-versions > b/sysdeps/unix/sysv/linux/arc/shlib-versions > new file mode 100644 > index ..c4d5d029812d > --- /dev/null > +++ b/sysdeps/unix/sysv/linux/arc/shlib-versions > @@ -0,0 +1,2 @@ > +DEFAULT GLIBC_2.21 > +ld=ld-linux.so.2 Is there a reason why you set the ABI baseline to GLIBC_2.21? Why not GLBIC_2.26? Thanks, Florian ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
