On 15/03/2024 19:07, Florian Weimer wrote: > * Горбешко Богдан: > >> I'm not going to install it system-wide, just to build it for >> cross-compiling a Golang project for a Debian Buster system, by >> specifying -rpath and --dynamic-linker. > Is this because you need a newer GCC? Not really, GCC 12 is just the default on Bullseye, GCC 10 seems to be available there too. So I should attempt to build and link with GCC 10? > If not, it's easier to use > pbuilder (or one of its variants) to build the program in a chroot with > Debian buster. Many people nowadays use podman or docker with a Debian > image for the same purpose. The pbuilder approach is perhaps preferable > if you already build a .deb archive, and podman can be scripted more > easily to build something that isn't. I don't really build .deb packages, Golang compiler produces one static binary, so that would be redundant. We already have a solution to build this in Docker, though the target test VPS is tight on resources and I wouldn't really like to mess with Docker there. My scenario is developing the project on one VPS, building it there and sending test builds (just copying one binary file, pretty easy) to another VPS where they are run. Previously they had the same Debian version, so this was a non-issue; recently I upgraded the first one to Bullseye, but the target VPS has some legacy and 3rd party software running, so an upgrade would be complicated and I postponed it for now. I could actually run the builds on the development VPS as well, migrate project data there and bind a remote port via SSH, but this would make it more prone to network interruptions. > > Thanks, > Florian >
* Горбешко Богдан:
> I'm not going to install it system-wide, just to build it for
> cross-compiling a Golang project for a Debian Buster system, by
> specifying -rpath and --dynamic-linker.
Is this because you need a newer GCC? If not, it's easier to use
pbuilder (or one of its variants) to build the program in a chroot with
Debian buster. Many people nowadays use podman or docker with a Debian
image for the same purpose. The pbuilder approach is perhaps preferable
if you already build a .deb archive, and podman can be scripted more
easily to build something that isn't.
Thanks,
Florian
I'm not going to install it system-wide, just to build it for
cross-compiling a Golang project for a Debian Buster system, by
specifying -rpath and --dynamic-linker.
On 15/03/2024 09:27, Florian Weimer wrote:
> * Горбешко Богдан via Libc-help:
>
>> Is that because it attempts to link against the system libstdc++,
>> which is too new and requires symbols not present in this glibc
>> version? Do I need to compile it myself? Or maybe even the whole GCC?
> Going back before 2.34 if the distribution is on 2.34 or later is not
> really possible. You need to build a whole cross-toolchain environment.
> It's easier to build on an older version of the distribution?
>
> Why do you need to go back 2.31? What kind of problem are you trying to
> solve?
>
> Thanks,
> Florian
>
* Горбешко Богдан via Libc-help:
> Is that because it attempts to link against the system libstdc++,
> which is too new and requires symbols not present in this glibc
> version? Do I need to compile it myself? Or maybe even the whole GCC?
Going back before 2.34 if the distribution is on 2.34 or later is not
really possible. You need to build a whole cross-toolchain environment.
It's easier to build on an older version of the distribution?
Why do you need to go back 2.31? What kind of problem are you trying to
solve?
Thanks,
Florian
Hi. I attempt to build glibc 2.31 on Debian GNU/Linux 12 Bookworm. It fails at: gcc -Wl,-rpath-link=/home/bodqhrohro/git/glibc-2.31-build:/home/bodqhrohro/git/glibc-2.31-build/math:/home/bodqhrohro/git/glibc-2.31-build/elf:/home/bodqhrohro/git/glibc-2.31-build/dlfcn:/home/bodqhrohro/git/glibc-2.31-build/nss:/home/bodqhrohro/git/glibc-2.31-build/nis:/home/bodqhrohro/git/glibc-2.31-build/rt:/home/bodqhrohro/git/glibc-2.31-build/resolv:/home/bodqhrohro/git/glibc-2.31-build/mathvec:/home/bodqhrohro/git/glibc-2.31-build/support:/home/bodqhrohro/git/glibc-2.31-build/crypt:/home/bodqhrohro/git/glibc-2.31-build/nptl -pie -Wl,-O1 -nostdlib -nostartfiles -o /home/bodqhrohro/git/glibc-2.31-build/support/links-dso-program -Wl,-z,combreloc -Wl,-z,relro -Wl,--hash-style=both /home/bodqhrohro/git/glibc-2.31-build/csu/Scrt1.o /home/bodqhrohro/git/glibc-2.31-build/csu/crti.o `gcc --print-file-name=crtbeginS.o` /home/bodqhrohro/git/glibc-2.31-build/support/links-dso-program.o -lstdc++ -lgcc -lgcc_s -Wl,-dynamic-linker=/home/bodqhrohro/git/glibc-2.31-build/lib/ld-linux-x86-64.so.2 /home/bodqhrohro/git/glibc-2.31-build/libc.so.6 /home/bodqhrohro/git/glibc-2.31-build/libc_nonshared.a -Wl,--as-needed /home/bodqhrohro/git/glibc-2.31-build/elf/ld.so -Wl,--no-as-needed -lgcc `gcc --print-file-name=crtendS.o` /home/bodqhrohro/git/glibc-2.31-build/csu/crtn.o /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/12/libstdc++.so: undefined reference to `fstat64@GLIBC_2.33' /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/12/libstdc++.so: undefined reference to `pthread_key_create@GLIBC_2.34' /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/12/libstdc++.so: undefined reference to `pthread_rwlock_unlock@GLIBC_2.34' /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/12/libstdc++.so: undefined reference to `pthread_detach@GLIBC_2.34' /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/12/libstdc++.so: undefined reference to `pthread_setspecific@GLIBC_2.34' /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/12/../../../x86_64-linux-gnu/libgcc_s.so.1: undefined reference to `_dl_find_object@GLIBC_2.35' /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/12/libstdc++.so: undefined reference to `arc4random@GLIBC_2.36' /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/12/libstdc++.so: undefined reference to `__libc_single_threaded@GLIBC_2.32' /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/12/libstdc++.so: undefined reference to `pthread_join@GLIBC_2.34' /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/12/libstdc++.so: undefined reference to `pthread_rwlock_wrlock@GLIBC_2.34' /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/12/libstdc++.so: undefined reference to `pthread_getspecific@GLIBC_2.34' /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/12/libstdc++.so: undefined reference to `pthread_key_delete@GLIBC_2.34' /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/12/libstdc++.so: undefined reference to `lstat@GLIBC_2.33' /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/12/libstdc++.so: undefined reference to `stat@GLIBC_2.33' /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/12/libstdc++.so: undefined reference to `pthread_once@GLIBC_2.34' /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/12/libstdc++.so: undefined reference to `pthread_rwlock_rdlock@GLIBC_2.34' /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/12/libstdc++.so: undefined reference to `pthread_create@GLIBC_2.34' collect2: error: ld returned 1 exit status make[2]: *** [../Rules:215: /home/bodqhrohro/git/glibc-2.31-build/support/links-dso-program] Error 1 Is that because it attempts to link against the system libstdc++, which is too new and requires symbols not present in this glibc version? Do I need to compile it myself? Or maybe even the whole GCC? I attempted to configure it without the SELinux support, but there's still the same problem.
[-- Attachment #1: Type: text/plain, Size: 772 bytes --] Hi, After running glibc testsuite with remote host testing using qemu, some stale qemu processes are left behind without terminating as follows: $ ps -el | grep qemu 1 S 23306 2592477 1 0 80 0 - 1101979 sigsus ? 00:00:00 qemu-ppc 1 S 23306 2592807 1 0 80 0 - 1101979 sigsus ? 00:00:00 qemu-ppc The cause of this stale processes are found to be from test cases *tst-scm_rights.c and tst-scm_rights-time64.c files(present at sysdeps/unix/sysv/linux/). *https://sourceware.org/glibc/wiki/Testing/Testsuite* *I referred the above link for checking if the tests can be disabled but didn't find. Is there any way to skip/disable individual test cases for glibc testsuite? If yes, how to do so? Thanks in advance. Regards, Yash
[-- Attachment #1: Type: text/plain, Size: 1382 bytes --] Hi there, You joined fubar back on November 14, 2021 and have been with us for 2 years and 4 months. We just wanted to wish you a: HAPPY ANNIVERSARY! Thanks for being a loyal drinking buddy! Use the link below to redeem your anniversary gift. Hurry, you only have 7 days until it expires. Collect them all to earn achievements and points! CLAIM YOUR ANNIVERSARY GIFT! https://www.fubar.com/recallclick.php?email=libc-help@sourceware.org&rg=TUc0d05qSTRNMjUzY0RoS05GWnRjbkpsUVV4Nk4xQkhhR1ZqT1dabFEzVkVUVmxyT0RWdmN6WmpiejA2T2xQMkZDUVhQZ2c4UU1TYVBlbGcrSXc9&t=YVdwVVZTdHROV1pPYjBjMVYzVnRSbkV3TlhabWRqRm9jRzlTZGpZNFluaDVjMHBIVkVkVVZEWlhUVDA2T3JlTXpKM2orcjh1c2ZScTFybEhNSTQ9&r=YXpsbU1tVTBWelF3V2tOek4yVndSMDFJVEc5SUszTlJXVkpPYUdrd1NYZ3hWVWxpVjFKdFlXeG1UVDA2T202azZiMldmaG1kdnhLMUkzdG9WUkk9.37 Cheers, -fubar family To unsubscribe or change your email settings, please use the following link: https://www.fubar.com/recallclick.php?email=libc-help@sourceware.org&rg=TUc0d05qSTRNMjUzY0RoS05GWnRjbkpsUVV4Nk4xQkhhR1ZqT1dabFEzVkVUVmxyT0RWdmN6WmpiejA2T2xQMkZDUVhQZ2c4UU1TYVBlbGcrSXc9&t=YVdwVVZTdHROV1pPYjBjMVYzVnRSbkV3TlhabWRqRm9jRzlTZGpZNFluaDVjMHBIVkVkVVZEWlhUVDA2T3JlTXpKM2orcjh1c2ZScTFybEhNSTQ9&r=YXpsbU1tVTBWelF3V2tOek4yVndSMDFJVEc5SUszTlJXVkpPYUdrd1NYZ3hWVWxpVjFKdFlXeG1UVDA2T202azZiMldmaG1kdnhLMUkzdG9WUkk9.2 fubar - 50 Woodside Plaza #433 - Redwood City, CA 94061
On 07/03/24 15:31, Aliaksey Kandratsenka wrote: > Thanks. > > So it turns out I also needed to undef _TIME_BITS. Since glibc errors whenever _TIME_BITS are set and _FILE_OFFSET_BITS aren't. No complaints. IMHO it is a very reasonable thing that glibc does there. But it makes things slightly riskier on our end. > > I have a question about a potentially longer term future. Do you guys plan to, say, default to _TIME_BITS=64 and _FILE_OFFSET_BITS=64 at any point? Asking because it would break my code (thankfully, it won't be silent breaking, but still). It was on my plan when I we started to effectively work on 64 bit time_t, but we decided this would case too much potential breakage (as debian is finding out recently). So I think it is unlikely that we will even change it. > > Should I consider something else to make my code more robust ? > > On Mon, Mar 4, 2024 at 7:04 AM Adhemerval Zanella Netto <adhemerval.zanella@linaro.org <mailto:adhemerval.zanella@linaro.org>> wrote: > > > > On 01/03/24 18:06, Aliaksey Kandratsenka via Libc-help wrote: > > Hi. > > > > In gperftools we have the feature to hook mmap calls which works by > > interposing over glibc's mmap. So it has to deal with off_t complexities. > > We don't use that offset argument, other than just passing it to real mmap > > implementation. I am also trying to support different Linux libc-s just for > > completeness. And musl being new enough and wise enough has always had > > 64-bit off_t (bionic hasn't and there is really no excuse...) > > > > So with that I need some means to detect 32-bit off_t that works across > > multiple libcs and has the highest hope of working in the future. > > > > By looking around, I choose to detect 32-bit-ness of off_t by looking at > > semi-obscure define _POSIX_V7_ILP32_OFF32: > > https://github.com/gperftools/gperftools/blob/37b59a206e36b405dcb2ac09d502875dd629a80b/src/mmap_hook.cc#L275 <https://github.com/gperftools/gperftools/blob/37b59a206e36b405dcb2ac09d502875dd629a80b/src/mmap_hook.cc#L275> > > > > It does seem to do the right thing across implementations I checked. Well > > mostly. > > > > These days, Debian folk are doing a massive 64-bit time_t transition (which > > also includes mass-enabling 64-bit off_t, at last) and they're rebuilding > > everything with _FILE_OFFSET_BITS=64. And my "approach" fails. > > https://buildd.debian.org/status/fetch.php?pkg=google-perftools&arch=armel&ver=2.15-1.1&stamp=1709166723&file=log <https://buildd.debian.org/status/fetch.php?pkg=google-perftools&arch=armel&ver=2.15-1.1&stamp=1709166723&file=log> > > > > Glibc doesn't adjust _POSIX_V7_ILP32_{BIGOFF,OFF32} defines based on > > _FILE_OFFSET_BITS. Perhaps rightly so. But with that situation I need some > > other, and hopefully more robust means to detect off_t width. > > > > I am thinking of 3 options: > > > > * Keep _POSIX_V7 thingy but also add a check for _FILE_OFFSET_BITS == 64. > > And then behave as if off_t is 32-bit. > > * #undef _FILE_OFFSET_BITS at the first line in mmap_hooks.cc. It will > > cause glibc on those legacy 32-bit off_t systems to define 32-bit off_t and > > give me right defines and my code will define mmap symbol with 32-bit > > offset arg and mmap64 symbol with 64-bit offset. And thus matching glibc. > > * just manually hardcode knowledge that glibc + > > You need to undefine _FILE_OFFSET_BITS to get the expected types for > off_t and off64_t on the mmap_hook.cc TU, since the whole idea is to > override the symbol. You can also try to poke on glibc internals and > use __off_t and __off64_t, which would not be redefined depending the > the preprocessor (but tying to internal implementation is always a bad > idea). > > So I would recommend this option, which seems to what you did and it is > what sanitizers do also [1]. > > > {i386,arm{el,hf},mips32,ppc32} has 32-bit off_t. But that leaves the > > question of how to deal with e.g. bionic (well, I could in principle say, > > bionic already being broken enough is only supported for 64-bit systems, > > which is where android systems are moving anyways) > > > > I am looking for any comments or suggestions. Particularly I'd like my fix > > to be robust w.r.t. any further glibc evolution. > > [1] https://github.com/llvm/llvm-project/blob/main/compiler-rt/lib/sanitizer_common/sanitizer_platform_limits_posix.cpp#L15 <https://github.com/llvm/llvm-project/blob/main/compiler-rt/lib/sanitizer_common/sanitizer_platform_limits_posix.cpp#L15> >
[-- Attachment #1: Type: text/plain, Size: 433 bytes --] Hello , Where have you been? Sativa da Cat FOB SnOwFlAk3 misses you on fubar and wants you back! He requested we send you this message. Don't leave him hangin!! Return to my home page - https://fubar.com/recall/646584549.27?uid_from=9220754&ibh=UjFwMVEwVlhlazFKZEN0Uk1sbEhVMjh6UW1ZMlVIQm9TSFZMU2t4MU5qTjJSalJzZFc5SGRFOXlSbGx2TjBOUVRXcGthRzU2UmxoRGVDOUZkWEZKVkRvNkc0cDNrTjJ2b1dFTUlCU0t6NklvMUE9PQ%3D%3D Cheers, - fubar Family
[-- Attachment #1: Type: text/plain, Size: 3901 bytes --] Thanks. So it turns out I also needed to undef _TIME_BITS. Since glibc errors whenever _TIME_BITS are set and _FILE_OFFSET_BITS aren't. No complaints. IMHO it is a very reasonable thing that glibc does there. But it makes things slightly riskier on our end. I have a question about a potentially longer term future. Do you guys plan to, say, default to _TIME_BITS=64 and _FILE_OFFSET_BITS=64 at any point? Asking because it would break my code (thankfully, it won't be silent breaking, but still). Should I consider something else to make my code more robust ? On Mon, Mar 4, 2024 at 7:04 AM Adhemerval Zanella Netto < adhemerval.zanella@linaro.org> wrote: > > > On 01/03/24 18:06, Aliaksey Kandratsenka via Libc-help wrote: > > Hi. > > > > In gperftools we have the feature to hook mmap calls which works by > > interposing over glibc's mmap. So it has to deal with off_t complexities. > > We don't use that offset argument, other than just passing it to real > mmap > > implementation. I am also trying to support different Linux libc-s just > for > > completeness. And musl being new enough and wise enough has always had > > 64-bit off_t (bionic hasn't and there is really no excuse...) > > > > So with that I need some means to detect 32-bit off_t that works across > > multiple libcs and has the highest hope of working in the future. > > > > By looking around, I choose to detect 32-bit-ness of off_t by looking at > > semi-obscure define _POSIX_V7_ILP32_OFF32: > > > https://github.com/gperftools/gperftools/blob/37b59a206e36b405dcb2ac09d502875dd629a80b/src/mmap_hook.cc#L275 > > > > It does seem to do the right thing across implementations I checked. Well > > mostly. > > > > These days, Debian folk are doing a massive 64-bit time_t transition > (which > > also includes mass-enabling 64-bit off_t, at last) and they're rebuilding > > everything with _FILE_OFFSET_BITS=64. And my "approach" fails. > > > https://buildd.debian.org/status/fetch.php?pkg=google-perftools&arch=armel&ver=2.15-1.1&stamp=1709166723&file=log > > > > Glibc doesn't adjust _POSIX_V7_ILP32_{BIGOFF,OFF32} defines based on > > _FILE_OFFSET_BITS. Perhaps rightly so. But with that situation I need > some > > other, and hopefully more robust means to detect off_t width. > > > > I am thinking of 3 options: > > > > * Keep _POSIX_V7 thingy but also add a check for _FILE_OFFSET_BITS == 64. > > And then behave as if off_t is 32-bit. > > * #undef _FILE_OFFSET_BITS at the first line in mmap_hooks.cc. It will > > cause glibc on those legacy 32-bit off_t systems to define 32-bit off_t > and > > give me right defines and my code will define mmap symbol with 32-bit > > offset arg and mmap64 symbol with 64-bit offset. And thus matching glibc. > > * just manually hardcode knowledge that glibc + > > You need to undefine _FILE_OFFSET_BITS to get the expected types for > off_t and off64_t on the mmap_hook.cc TU, since the whole idea is to > override the symbol. You can also try to poke on glibc internals and > use __off_t and __off64_t, which would not be redefined depending the > the preprocessor (but tying to internal implementation is always a bad > idea). > > So I would recommend this option, which seems to what you did and it is > what sanitizers do also [1]. > > > {i386,arm{el,hf},mips32,ppc32} has 32-bit off_t. But that leaves the > > question of how to deal with e.g. bionic (well, I could in principle say, > > bionic already being broken enough is only supported for 64-bit systems, > > which is where android systems are moving anyways) > > > > I am looking for any comments or suggestions. Particularly I'd like my > fix > > to be robust w.r.t. any further glibc evolution. > > [1] > https://github.com/llvm/llvm-project/blob/main/compiler-rt/lib/sanitizer_common/sanitizer_platform_limits_posix.cpp#L15 >
[-- Attachment #1: Type: text/plain, Size: 1281 bytes --] Hi Morten, On Mon, Mar 04, 2024 at 06:52:10PM +0100, Alejandro Colomar wrote: > > logb: > > The formula "floor(log2(x))" should be "floor(log2(fabs(x)))". (Or > > ...abs(...) if it's meant to be math and not C.) I've applied thge following patch: commit 1d83ce827aac984a26430b4f6107182f4b076874 (HEAD -> contrib, alx/contrib) Author: Alejandro Colomar <alx@kernel.org> Date: Tue Mar 5 00:20:09 2024 +0100 logb.3: logb(x) is floor(log2(fabs(x))) log2(3) doesn't accept negative input, but it seems logb(3) does accept it. Link: <https://lore.kernel.org/linux-man/ZeYKUOKYS7G90SaV@debian/T/#u> Reported-by: Morten Welinder <mwelinder@gmail.com> Cc: Adhemerval Zanella Netto <adhemerval.zanella@linaro.org> Signed-off-by: Alejandro Colomar <alx@kernel.org> diff --git a/man3/logb.3 b/man3/logb.3 index 7cbb2470a..7a1ad2f4a 100644 --- a/man3/logb.3 +++ b/man3/logb.3 @@ -58,7 +58,7 @@ .SH DESCRIPTION is 2, .BI logb( x ) is equal to -.BI floor(log2( x ))\fR, +.BI floor(log2(fabs( x )))\f[R],\f[] except that it is probably faster. .P If I'll push it tomorrow. Have a lovely night! Alex -- <https://www.alejandro-colomar.es/> Looking for a remote C programming job at the moment. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #1: Type: text/plain, Size: 308 bytes --] Hi Adhemerval, On Mon, Mar 04, 2024 at 03:47:26PM -0300, Adhemerval Zanella Netto wrote: > It does seems to be an error on manual, could you send a patch to fix it? Sure! Have a lovely night! Alex -- <https://www.alejandro-colomar.es/> Looking for a remote C programming job at the moment. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --]
On 04/03/24 14:52, Alejandro Colomar wrote:
> Hi Morten,
>
> On Thu, Feb 29, 2024 at 07:28:10PM -0500, Morten Welinder wrote:
>> I came across some minor issues in some math man pages.
>>
>> M.
>>
>>
>>
>> logb:
>> The formula "floor(log2(x))" should be "floor(log2(fabs(x)))". (Or
>> ...abs(...) if it's meant to be math and not C.)
>
> Confirmed. This is a bug in glibc too, BTW. That text seems to be
> copied from their manual.
>
> ISO C says this function is specified in ANSI/IEEE 854, but I don't have
> access to that document, so I'm not sure what's the specification of the
> function. I'm not sure if it should fail for negative values (like
> log2(3)) or not; although the standard mentions the behavior for
> negative infinity, so it probably is specified to work for negative
> values too.
>
> So, the behavior of the function seems to be correct, and it's just the
> manual that needs to be fixed.
>
> I've CCed glibc, in case they want to comment. But yeah, your
> suggestion seems correct.
It does seems to be an error on manual, could you send a patch to fix it?
[-- Attachment #1: Type: text/plain, Size: 1085 bytes --] Hi Morten, On Thu, Feb 29, 2024 at 07:28:10PM -0500, Morten Welinder wrote: > I came across some minor issues in some math man pages. > > M. > > > > logb: > The formula "floor(log2(x))" should be "floor(log2(fabs(x)))". (Or > ...abs(...) if it's meant to be math and not C.) Confirmed. This is a bug in glibc too, BTW. That text seems to be copied from their manual. ISO C says this function is specified in ANSI/IEEE 854, but I don't have access to that document, so I'm not sure what's the specification of the function. I'm not sure if it should fail for negative values (like log2(3)) or not; although the standard mentions the behavior for negative infinity, so it probably is specified to work for negative values too. So, the behavior of the function seems to be correct, and it's just the manual that needs to be fixed. I've CCed glibc, in case they want to comment. But yeah, your suggestion seems correct. Have a lovely day! Alex -- <https://www.alejandro-colomar.es/> Looking for a remote C programming job at the moment. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --]
On 01/03/24 18:06, Aliaksey Kandratsenka via Libc-help wrote: > Hi. > > In gperftools we have the feature to hook mmap calls which works by > interposing over glibc's mmap. So it has to deal with off_t complexities. > We don't use that offset argument, other than just passing it to real mmap > implementation. I am also trying to support different Linux libc-s just for > completeness. And musl being new enough and wise enough has always had > 64-bit off_t (bionic hasn't and there is really no excuse...) > > So with that I need some means to detect 32-bit off_t that works across > multiple libcs and has the highest hope of working in the future. > > By looking around, I choose to detect 32-bit-ness of off_t by looking at > semi-obscure define _POSIX_V7_ILP32_OFF32: > https://github.com/gperftools/gperftools/blob/37b59a206e36b405dcb2ac09d502875dd629a80b/src/mmap_hook.cc#L275 > > It does seem to do the right thing across implementations I checked. Well > mostly. > > These days, Debian folk are doing a massive 64-bit time_t transition (which > also includes mass-enabling 64-bit off_t, at last) and they're rebuilding > everything with _FILE_OFFSET_BITS=64. And my "approach" fails. > https://buildd.debian.org/status/fetch.php?pkg=google-perftools&arch=armel&ver=2.15-1.1&stamp=1709166723&file=log > > Glibc doesn't adjust _POSIX_V7_ILP32_{BIGOFF,OFF32} defines based on > _FILE_OFFSET_BITS. Perhaps rightly so. But with that situation I need some > other, and hopefully more robust means to detect off_t width. > > I am thinking of 3 options: > > * Keep _POSIX_V7 thingy but also add a check for _FILE_OFFSET_BITS == 64. > And then behave as if off_t is 32-bit. > * #undef _FILE_OFFSET_BITS at the first line in mmap_hooks.cc. It will > cause glibc on those legacy 32-bit off_t systems to define 32-bit off_t and > give me right defines and my code will define mmap symbol with 32-bit > offset arg and mmap64 symbol with 64-bit offset. And thus matching glibc. > * just manually hardcode knowledge that glibc + You need to undefine _FILE_OFFSET_BITS to get the expected types for off_t and off64_t on the mmap_hook.cc TU, since the whole idea is to override the symbol. You can also try to poke on glibc internals and use __off_t and __off64_t, which would not be redefined depending the the preprocessor (but tying to internal implementation is always a bad idea). So I would recommend this option, which seems to what you did and it is what sanitizers do also [1]. > {i386,arm{el,hf},mips32,ppc32} has 32-bit off_t. But that leaves the > question of how to deal with e.g. bionic (well, I could in principle say, > bionic already being broken enough is only supported for 64-bit systems, > which is where android systems are moving anyways) > > I am looking for any comments or suggestions. Particularly I'd like my fix > to be robust w.r.t. any further glibc evolution. [1] https://github.com/llvm/llvm-project/blob/main/compiler-rt/lib/sanitizer_common/sanitizer_platform_limits_posix.cpp#L15
[-- Attachment #1: Type: text/plain, Size: 2288 bytes --] Hi. In gperftools we have the feature to hook mmap calls which works by interposing over glibc's mmap. So it has to deal with off_t complexities. We don't use that offset argument, other than just passing it to real mmap implementation. I am also trying to support different Linux libc-s just for completeness. And musl being new enough and wise enough has always had 64-bit off_t (bionic hasn't and there is really no excuse...) So with that I need some means to detect 32-bit off_t that works across multiple libcs and has the highest hope of working in the future. By looking around, I choose to detect 32-bit-ness of off_t by looking at semi-obscure define _POSIX_V7_ILP32_OFF32: https://github.com/gperftools/gperftools/blob/37b59a206e36b405dcb2ac09d502875dd629a80b/src/mmap_hook.cc#L275 It does seem to do the right thing across implementations I checked. Well mostly. These days, Debian folk are doing a massive 64-bit time_t transition (which also includes mass-enabling 64-bit off_t, at last) and they're rebuilding everything with _FILE_OFFSET_BITS=64. And my "approach" fails. https://buildd.debian.org/status/fetch.php?pkg=google-perftools&arch=armel&ver=2.15-1.1&stamp=1709166723&file=log Glibc doesn't adjust _POSIX_V7_ILP32_{BIGOFF,OFF32} defines based on _FILE_OFFSET_BITS. Perhaps rightly so. But with that situation I need some other, and hopefully more robust means to detect off_t width. I am thinking of 3 options: * Keep _POSIX_V7 thingy but also add a check for _FILE_OFFSET_BITS == 64. And then behave as if off_t is 32-bit. * #undef _FILE_OFFSET_BITS at the first line in mmap_hooks.cc. It will cause glibc on those legacy 32-bit off_t systems to define 32-bit off_t and give me right defines and my code will define mmap symbol with 32-bit offset arg and mmap64 symbol with 64-bit offset. And thus matching glibc. * just manually hardcode knowledge that glibc + {i386,arm{el,hf},mips32,ppc32} has 32-bit off_t. But that leaves the question of how to deal with e.g. bionic (well, I could in principle say, bionic already being broken enough is only supported for 64-bit systems, which is where android systems are moving anyways) I am looking for any comments or suggestions. Particularly I'd like my fix to be robust w.r.t. any further glibc evolution.
* Godmar Back via Libc-help:
> The implementation of the obsolescent makecontext/getcontext/swapcontext
> family of functions on x86_64 [1] appears to save a selection of registers.
>
> These include callee-saved regs like rbx, rbp, r12-r15, but also
> caller-saved regs like rdi, rsi, rdx, rcx. On the floating point side, it
> saves mxcsr, the x87 FPU state via fnstenv, but not the xmm SSE register.
> All of these floating point registers are callee-saved based on the AMD64
> ABI [2].
%rdi, %rsi, %rdx, %rcx are argument registers and need to be restored
for makecontext to work correctly. As far as I can see, getcontext
wouldn't need to save them, but they need to be restored.
The handling of what is now considered per-thread state (such as
floating point control words or signal masks) is inconsistent. I
think this is just due to the age of these interfaces, and not
something that was designed explicitly.
[-- Attachment #1: Type: text/plain, Size: 431 bytes --] Hello , Where have you been? Bomb Me Pls Moira xiHoRx misses you on fubar and wants you back! She requested we send you this message. Don't leave her hangin!! Return to my home page - https://fubar.com/recall/636120731.27?uid_from=5533478&ibh=VjJ4alpXOVdiSFpKTWsxcGQyNVZjSEpXU2psdVRrRnphemN6WjFsc01UWk5iWGcwZVRkS1NqSTJTVVppT0VGaGVHTnljV0ZKYmxKNlV6QkhMMGQ2YXpvNnBDY1ZOREh2dVVBZ1N5TWl5b3NjbUE9PQ%3D%3D Cheers, - fubar Family
[-- Attachment #1: Type: text/plain, Size: 2372 bytes --] Hello from near Paris in France, On 2/14/24 05:59, Lucas Augusto Valentim Dantas via Libc-help wrote: > Hello, I have been playing around with Doom's source code, the 90s one, and I have noticed that it has a header included named errnos.h that I have recently learned that it was actually present in glibc beginning from 2.0.0 (I think) until 2.0.7. Could anyone shed light on why it was added to glibc and later removed? I can't explain why it was added. I can guess why it was removed. > > https://sources.debian.org/src/glibc/2.0.7t-1/sysdeps/unix/sysv/linux/errnos.h/ > https://github.com/id-Software/DOOM/blob/master/linuxdoom-1.10/i_video.c#L49 Maybe because errnos.h is no more in standard C or in POSIX. But errno.h is standard. See also https://man7.org/linux/man-pages/man3/errno.3.html <https://man7.org/linux/man-pages/man3/errno.3.html>> and https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf or buy from your ISO representative <https://www.iso.org/standard/74528.html> the formal C standard book. From my human (and perhaps wrong) memory, errnos.h existed on old operating systems and computers like Sun4/110 workstation with a SunOS3.5 (this was in the early 1990s, I worked then as a software developer at CEA <https://www.cea.fr/>). I don't have that header file on my current Debian/Sid/amd64 desktop. Today, using errno actually requires the #include <errno.h> preprocessor directive, and on my Linux system it is a macro defined in /usr/include/errno.h as > rimski.x86_64 ~/misc-basile 8:45 .0 %grep errno_/usr/include/errno.h_ > * ISO C99 Standard: 7.5 Errors <errno.h> > #include <bits/errno.h> > extern int *__errno_location (void) __THROW __attribute_const__; > # define errno (*__errno_location ()) > #endif /* errno.h */ And today my pet open source project is the RefPerSys <http://refpersys.org/> inference engine (*REF*lective *PER*sistent *SYS*tem, GPLv3+ licensed) on https://github.com/RefPerSys/RefPerSys/ ; if you know someone who wants to contribute, please forward to him/her this email. Thanks for reading. Regards <https://man7.org/linux/man-pages/man3/errno.3.html>> -- Basile Starynkevitch<basile@starynkevitch.net> (only mine opinions / les opinions sont miennes uniquement) 92340 Bourg-la-Reine, France web page: starynkevitch.net/Basile/ See/voir:https://github.com/RefPerSys/RefPerSys
On Wed, 2024-02-14 at 04:59 +0000, Lucas Augusto Valentim Dantas via Libc-help wrote: > Hello, I have been playing around with Doom's source code, the 90s > one, and I have noticed that it has a header included named errnos.h > that I have recently learned that it was actually present in glibc > beginning from 2.0.0 (I think) until 2.0.7. Could anyone shed light > on why it was added to glibc and later removed? > > https://sources.debian.org/src/glibc/2.0.7t-1/sysdeps/unix/sysv/linux/errnos.h/ > https://github.com/id-Software/DOOM/blob/master/linuxdoom-1.10/i_video.c#L49 Judging by the commit 5107cf1d7d27f17c6de68ec15a8e8d9dd5b471c1 description from 1997: > * sysdeps/mach/hurd/errnos.h: -> .../bits/errno.h > * sysdeps/standalone/arm/errnos.h: Likewise. > * sysdeps/stub/errnos.h: Likewise. > * sysdeps/unix/bsd/bsd4.4/errnos.h: Likewise. > * sysdeps/unix/sysv/linux/errnos.h: Likewise. all platform-specific `errnos.h` were merged into a single file `errno.h`.
[-- Attachment #1: Type: text/plain, Size: 481 bytes --] Hello, I have been playing around with Doom's source code, the 90s one, and I have noticed that it has a header included named errnos.h that I have recently learned that it was actually present in glibc beginning from 2.0.0 (I think) until 2.0.7. Could anyone shed light on why it was added to glibc and later removed? https://sources.debian.org/src/glibc/2.0.7t-1/sysdeps/unix/sysv/linux/errnos.h/ https://github.com/id-Software/DOOM/blob/master/linuxdoom-1.10/i_video.c#L49
Hi Florian,
On 2/11/24 14:04, Florian Weimer wrote:
> * Charalampos Mitrodimas via Libc-help:
>
>> I've encountered a potential memory leak in libc, specifically within
>> the DNS resolution functions, as identified by Valgrind. The leak
>> involves __libc_alloc_buffer_allocate and related functions. Here's the
>> Valgrind output snippet:
>>
>> ==4151== 156 bytes in 1 blocks are definitely lost in loss record
>> 730 of 1,029
>> ==4151== at 0x4848899: malloc (in
>> /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
>> ==4151== by 0x4D15048: __libc_alloc_buffer_allocate
>> (alloc_buffer_allocate.c:26)
>> ==4151== by 0x4DBDC65: alloc_buffer_allocate (alloc_buffer.h:143)
>> ==4151== by 0x4DBDC65: __resolv_conf_allocate (resolv_conf.c:391)
>> ==4151== by 0x4DB8D0A: __resolv_conf_load (res_init.c:599)
> This is unfortunately not very illuminating because the struct
> resolv_conf functions are reference-counted. If there's a counter
> management bug somewhere, it would be reported like this by valgrind.
>
>> This issue arose in an application using Rust's email library Lettre,
>> ultimately traced back to libc during DNS resolution. Could you please
>> advise if this is a known issue and recommend any steps to address it?
>> I'm willing to contribute a fix, but want to make sure this is of
>> concern for the libc team, before starting the investigation.
> I don't recall a problem like this being reported before. Can you
> reproduce it on a recent glibc version? We have some cases of
> known/intended leaks (if the memory that can be leaked is bounded for
> the life-time of the process), but that doesn't apply here. It
> certainly looks like something we'd want to fix.
Thanks for replying!
Yes, I'll try to provide more information, debug different
versions and reach back.
* Charalampos Mitrodimas via Libc-help: > I've encountered a potential memory leak in libc, specifically within > the DNS resolution functions, as identified by Valgrind. The leak > involves __libc_alloc_buffer_allocate and related functions. Here's the > Valgrind output snippet: > > ==4151== 156 bytes in 1 blocks are definitely lost in loss record > 730 of 1,029 > ==4151== at 0x4848899: malloc (in > /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so) > ==4151== by 0x4D15048: __libc_alloc_buffer_allocate > (alloc_buffer_allocate.c:26) > ==4151== by 0x4DBDC65: alloc_buffer_allocate (alloc_buffer.h:143) > ==4151== by 0x4DBDC65: __resolv_conf_allocate (resolv_conf.c:391) > ==4151== by 0x4DB8D0A: __resolv_conf_load (res_init.c:599) This is unfortunately not very illuminating because the struct resolv_conf functions are reference-counted. If there's a counter management bug somewhere, it would be reported like this by valgrind. > This issue arose in an application using Rust's email library Lettre, > ultimately traced back to libc during DNS resolution. Could you please > advise if this is a known issue and recommend any steps to address it? > I'm willing to contribute a fix, but want to make sure this is of > concern for the libc team, before starting the investigation. I don't recall a problem like this being reported before. Can you reproduce it on a recent glibc version? We have some cases of known/intended leaks (if the memory that can be leaked is bounded for the life-time of the process), but that doesn't apply here. It certainly looks like something we'd want to fix. Thanks, Florian
Hello, I've encountered a potential memory leak in libc, specifically within the DNS resolution functions, as identified by Valgrind. The leak involves __libc_alloc_buffer_allocate and related functions. Here's the Valgrind output snippet: ==4151== 156 bytes in 1 blocks are definitely lost in loss record 730 of 1,029 ==4151== at 0x4848899: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so) ==4151== by 0x4D15048: __libc_alloc_buffer_allocate (alloc_buffer_allocate.c:26) ==4151== by 0x4DBDC65: alloc_buffer_allocate (alloc_buffer.h:143) ==4151== by 0x4DBDC65: __resolv_conf_allocate (resolv_conf.c:391) ==4151== by 0x4DB8D0A: __resolv_conf_load (res_init.c:599) ==4151== by 0x4DBD85E: __resolv_conf_get_current (resolv_conf.c:140) ==4151== by 0x4DB9394: __res_vinit (res_init.c:628) ==4151== by 0x4DBE82F: maybe_init (resolv_context.c:122) ==4151== by 0x4DBE82F: context_get (resolv_context.c:184) ==4151== by 0x4DBE82F: context_get (resolv_context.c:176) ==4151== by 0x4DBE82F: __resolv_context_get (resolv_context.c:195) ==4151== by 0x4D78C87: get_nss_addresses (getaddrinfo.c:617) ==4151== by 0x4D78C87: gaih_inet (getaddrinfo.c:1179) ==4151== by 0x4D78C87: getaddrinfo (getaddrinfo.c:2397) ==4151== by 0x4A7108E: <std::sys_common::net::LookupHost as core::convert::TryFrom<(&str,u16)>>::try_from::{{closure}} (net.rs:207) ==4151== by 0x4A6A105: <(&str,u16) as std::net::socket_addr::ToSocketAddrs>::to_socket_addrs (small_c_string.rs:43) ==4151== by 0x495356A: lettre::transport::smtp::client::net::NetworkStream::connect::try_connect (net.rs:104) ==4151== by 0x49532F1: lettre::transport::smtp::client::net::NetworkStream::connect (net.rs:139) This issue arose in an application using Rust's email library Lettre, ultimately traced back to libc during DNS resolution. Could you please advise if this is a known issue and recommend any steps to address it? I'm willing to contribute a fix, but want to make sure this is of concern for the libc team, before starting the investigation. Thank you for your support. Charalampos Mitrodimas
[-- Attachment #1: Type: text/plain, Size: 4625 bytes --] Hello, If anybody can explain how to install the adviced patch finaly it will help myself so thanks you in advance, Regards. Dorian Rosse. ________________________________ De : Libc-help <libc-help-bounces+dorianbrice=hotmail.fr@sourceware.org> de la part de Dorian ROSSE via Libc-help <libc-help@sourceware.org> Envoyé : vendredi, février 2, 2024 10:41:27 AM À : Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>; libc-help <libc-help@sourceware.org>; Khem Raj <raj.khem@gmail.com> Objet : Re: Libc mips32 mips something can't be update on my Ubuntu server 22 04 who do fail glibc who be a root hacking Hello, Today i had checked if i can download your file using wget but unfortunately it download a file wrong called index.html finally thanks you in advance to explain to myself why i can't download your file, Regards. Dorian Rosse. ________________________________ From: Adhemerval Zanella Netto <adhemerval.zanella@linaro.org> Sent: Thursday, February 1, 2024 9:58:42 PM To: Dorian ROSSE <dorianbrice@hotmail.fr>; libc-help <libc-help@sourceware.org>; Khem Raj <raj.khem@gmail.com> Subject: Re: Libc mips32 mips something can't be update on my Ubuntu server 22 04 who do fail glibc who be a root hacking The patch is https://patchwork.sourceware.org/project/glibc/patch/20240201174103.798138-1-adhemerval.zanella@linaro.org/ if you want to check this out. On 01/02/24 16:41, Dorian ROSSE wrote: > You speak hard things for myself so i understand you will send a patch but for why it is misunderstood finally thanks you in advance to repair my server, > > Regards. > > > Dorian Rosse. > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ > *From:* Adhemerval Zanella Netto <adhemerval.zanella@linaro.org> > *Sent:* Thursday, February 1, 2024 6:28:50 PM > *To:* Dorian ROSSE <dorianbrice@hotmail.fr>; libc-help <libc-help@sourceware.org>; Khem Raj <raj.khem@gmail.com> > *Subject:* Re: Libc mips32 mips something can't be update on my Ubuntu server 22 04 who do fail glibc who be a root hacking > > Khem Raj has raised this and the clone3 implementation is broken > on o32. I will send the patch I have, it fixes the issues I > saw on LE and BE. > > On 01/02/24 12:04, Dorian ROSSE via Libc-help wrote: >> Libc mips32 mips something is a group of libc programs who fails to update so thanks you in advance to help myself repair the problem then i will i hope update glibc, >> >> Regards. >> >> >> Dorian Rosse. >> ________________________________ >> From: Dorian ROSSE <dorianbrice@hotmail.fr> >> Sent: Thursday, February 1, 2024 3:46:55 PM >> To: libc-help <libc-help@sourceware.org>; Dorian ROSSE <dorianbrice@hotmail.fr> >> Subject: Re: Libc mips32 mips something can't be update on my Ubuntu server 22 04 who do fail glibc who be a root hacking >> >> (this is a mips problem of update who forbid to update glibc) >> >> Thanks you in advance to help myself repair the update problem, >> >> Regards. >> >> >> Dorian Rosse. >> ________________________________ >> From: Libc-help <libc-help-bounces+dorianbrice=hotmail.fr@sourceware.org> on behalf of Dorian ROSSE via Libc-help <libc-help@sourceware.org> >> Sent: Thursday, February 1, 2024 3:28:37 PM >> To: libc-help <libc-help@sourceware.org> >> Subject: Libc mips32 mips something can't be update on my Ubuntu server 22 04 who do fail glibc who be a root hacking >> >> Hello, >> >> >> Libc mips32 mips something can't be update on my Ubuntu server 22 04 who do fail glibc who be a root hacking so thanks you to repair my problem because now with the hacking my system is frozen, >> >> Regards. >> >> >> Dorian Rosse.