IRC channel logs

<ZhaoM>hi has anyone tried to debug inside glibc using gdb?

<ZhaoM>I found this page but it does not work for me. https://darnassus.sceen.net/~hurd-web/faq/debugging_inside_glibc/

<ZhaoM>If futher information is needed please leave a message and I will describe the situation more clearly in the mail list

<youpi>sneek: later tell ZhaoM I'm surprised by the LD_LIBRARY_PATH / PRELOAD hint, there is no reason why they could help

<sneek>Got it.

<youpi>sneek: later tell ZhaoM yes, "doesn't work" is not precise enough to be able to tell anything. Really it should "just work"

<sneek>Okay.

<ZhaoM>good afternoon

<sneek>Welcome back ZhaoM, you have 2 messages!

<sneek>ZhaoM, youpi says: I'm surprised by the LD_LIBRARY_PATH / PRELOAD hint, there is no reason why they could help

<sneek>ZhaoM, youpi says: yes, "doesn't work" is not precise enough to be able to tell anything. Really it should "just work"

<ZhaoM>ok

<crupest>I may want to ask a very stupid question. How can I get the info of all block devices on Hurd like `lsblk` on Linux?

<crupest>Because I use a pre-installed image to run Hurd. When I compile something, this disk is full and I have to expand it. The image contains a about 4G ext2 partition.

<crupest>I've done the resize by attaching the virtual disk to another Linux Debian VM. Obviously, I need to use LiveCD or some method like this. But I really wonder how can I lsblk?

<youpi>crupest: it's not stupid at all :)

<youpi>lsblk was not ported so it won't work as such, you can however use stat /dev/sd0 and such to probe the size of disks

<crupest>Actually I use df

<crupest>It works

<crupest>But it does not show the full disk info

<youpi>what info do you need

<youpi>?

<crupest>At lease I need to know the block file is which... in /dev

<youpi>doesn't df show that?

<crupest>Yes

<youpi>df -h . gives me:

<youpi>/dev/wd3 49G 26G 22G 55% /

<youpi>then stat /dev/wd3 will tell me the disk size

<crupest>dev/wd0s1 62914560 4139164 55629684 7% /

<crupest>Why do I have a s1

<youpi>it's the first partition

<crupest>I mean why you don't have s1. I guess it is wd0. And I fdisk on wd0

<youpi>I just didn't partition my disk

<crupest>You can't fdisk wd0s1

<youpi>sure it's the disk that you partition into partitions

<youpi>there's no notion of subpartition

<crupest>I think I know the problem... That is, you can't get a tree...

<youpi>what do you actually try to achieve?

<youpi>always remember the xy problem

<youpi> https://xyproblem.info/

<crupest>What I want to achieve is that how can I know the real block device file in /dev, then I can fdsik it. Currently I'm guessing it from the df output. From the partition wd0s1 to the wd0.

<crupest>Good material for the wisdom of asking skill. I actually should learn.

<youpi>to get from a partition to the underlying disk, it's systematically removing s<nn>

<youpi>just like on linux with sda<nn> etc.

<crupest>I mean it can be guessed, of course. And I did it. I just wonder if there is a way that I can directly get the block device info like lsblk. It lists all the block devices on my machine. As I can see all the numbers are listed in /dev, while Linux only list what is actually attached.

<youpi>we don't have a dynamic /dev yet indeed

<youpi>again, what is your use case exactly?

<youpi>is it to determine all disks that are available? (that's not currently implemented, you have to just probe all possible /dev/[hsw]d[0-9])

<crupest>That's what I mean.

<youpi>is it to determine the disk that your fs is currently mounted from? you can "fsysopts ." for that

<crupest>To be honest, I have no use case for this problem. Sorry.

<crupest>I just wonder whether there is something like lsblk.

<youpi>not yet

<crupest>The problem is what you said. One way to determine the disks available. Just a curious problem. Sorry

<crupest>Forgive me. I do have another problem, which is more practical... What's the correct c macro to detect Hurd? The abseil use a lot of macro to detect OS and the features it support.

<crupest>What I currently found is __GNU__

<youpi>that is it yes

<crupest>#elif defined(__linux__) || defined(__APPLE__) || defined(__FreeBSD__) || \ defined(_AIX) || defined(__ros__) || defined(__native_client__) || \ defined(__asmjs__) || defined(__EMSCRIPTEN__) || defined(__Fuchsia__) || \ defined(__sun) || defined(__myriad2__) || defined(__HAIKU__) || \ defined(__OpenBSD__) || defined(__NetBSD__) || defined(__QNX__) || \ defined(__VXWORKS__) || defined(__hexagon__)

<crupest>This is how it detects mmap

<youpi>u

<youpi>h

<youpi>could it perhaps revert the test ? :)

<youpi>mmap is available basically everywhere but some very special OSes

<youpi>but yes, sure, you can add || defined(__GNU__)

<crupest>I did. It failed to build before. And I found it is due to missed mmap.

<crupest>I think I should add it to more places.

<youpi>you can probably grep for __linux__ to find the other places

<youpi>linux and hurd use the same glibc, so most support is just the same

<crupest>Good idea.

<crupest>I have tried to fix building of some libs. Most of them are misdetect of Hurd.

<crupest>One lib of google used in grpc even uses __mach__ to dectect macOS....

<youpi>yes, that's quite common

<youpi>they confuse kernel with os

<youpi>you then need to add __APPLE__ to fix the confusion

<crupest>But it will break on Hurd, won't it?

<youpi>that depends what it does with it

<youpi>some pieces of mach are indeed present both on darwin and on GNU/Hurd

<youpi>others aren't

<crupest>They include a macOS SDK header...

<crupest>I'll try to push some patches to upstream. If they don't accept, thanks to debian own package patch system, it can be added to debian patch if possible.

<crupest>#elif defined(__MACH__) uint32_t size = 0; int ret = _NSGetExecutablePath(nullptr, &size); if (ret != -1) {

<crupest>This one of the most typical error.

<crupest>_NSGetExecutablePath is OSX api. But it use __MACH__ to detect it.

<youpi>&& defined(__APPLE__) should be added

<youpi>NS is really just macos

<crupest>Yeah

<crupest>I'm not sure whether some api supported on Linux are supported on Hurd. mmap is the simpliest one to determine, while others are not that easy.

<crupest>Looks like __linux__ is used for POSIX.1-2001 detection in abseil.

<youpi>that's a common mispattern unfortunately, yes

<crupest>But I'm not sure if Hurd is all compitable to POSIX.

<youpi>it essentially is

<crupest>I might express it wrongly. The problem here is abseil uses macros to detect platform and check some table, maybe, (to see if it is POSIX.1-2001 compitible or other features). I don't know how they get the "table". The problem is I don't have the table of Hurd. The most mentioned standard is POSIX, apparently. The OS might have clear info of whether it supports the api whether because they are posix-compible or other special documents.

<crupest>I'm not sure whether one posix is compitible in Hurd...

<crupest>For example, mmap

<youpi>the table is essentially the C headers

<crupest> Checks whether the platform has an mmap(2) implementation as defined in// POSIX.1-2001.

<youpi>other tables would always risk getting out of date very quickly

<crupest>So, if the compilation succeeds, aka, the symbols are defined, the api is likely usable?

<crupest>In hurd?

<youpi>most often yes

<youpi>in some cases there are ENOSYS stubs, but it's rare

<crupest>I see.

<crupest>Abseil should have a robust unit tests. I'll have a try and show the result later. Thanks for your answers.

<youpi>thanks for your contribution !

<crupest>You are welcome. Compared to kernel, this is much easier for me. Hahaha.

<crupest>Emmm, unit test passed on a death test. Where is the core file?

<crupest>failed

<crupest>sorry

<crupest>let me search the doc

<youpi>the core file should be in the current directoy

<crupest>Ah. It is triggered by dpkg-buildpackage and cmake. I have the search the real cwd

<crupest>No worries.

<youpi>don't hesitate to post the upstream patch to the debian-hurd mailing list so we can already upload a package in unreleased to unlock the dependencies (webrtc, gst-plugins-bad, etc.)

<crupest>youpi: Of cource I'll do that.

<crupest>I might have to ask you again...

<crupest>find . -name '*core*'

<crupest>An from the console, I know that it dies for SIGABT

<crupest>and it handled by crash server.

<youpi>what does your /servers/crash point to?

<crupest>What is 'point to'? The console writes /hurd/crash: ...

<youpi>ls -l /servers/crash

<youpi>since it's a symlink

<crupest>Emmm. My hurd dies. Because I ls /servers ...

<crupest>\/servers/crash -> crash-dump-core

<crupest>I realize I have to sudo

<youpi>to do what?

<crupest>sudo ls -ld /servers/crash

<crupest>Otherwise ls will be stuck.

<youpi>? that's odd, you should n't have to, it's all o+r

<crupest>Emmm

<crupest>It works now, after I reboot.

<crupest>But last boot, ls stucks. And I ls /servers, hurd dies.

<youpi>"dies" is not technically precise enough

<crupest>ssh stops. ssh again has no response. Switch to vm screen, I can input things, but nothing happeds

<crupest>Maybe the virtualbox problem.

<youpi>no, probably you triggered something that put some servers in /servers get in a loop

<crupest>Actually I have a more serious problem. My hurd can only detect one core.

<crupest>youpi: that's reasonable

<youpi> https://darnassus.sceen.net/~hurd-web/faq/smp/

<crupest>Let me check the source of the test to see that it has been done with fork.

<crupest>I suspect, /hurd/crash --dump-core hangs, its process state is S<o. The test forked process is Huf. The logic is gtest want to ensure assert work. So it forks a process that triggers SIGABT, and wait for it. But /hurd/crash catch the signal and hangs. Then the test process waits forever.

<youpi>crupest: are you testing on hurd-i386 or hurd-amd64?

<crupest>When I killed crash and the forked process. Test failed with a timeout.

<crupest>amd64

<youpi>crash doesn't work there yet

<crupest>Ah

<crupest>Can I disable it?

<youpi>yes, just symlink /servers/crash to the crash-term server

<crupest>I'll try a 32 verison

<crupest>OK

<crupest>BTW, do you use a pre-installed image or installed one via LiveCD?

<youpi>easiest is to just use the preinstalled

<crupest>I see. I'll setup a 32 vm

<crupest>93% tests passed, 15 tests failed out of 221

<crupest>Better than I expected.

<crupest>Actually not that much. This is counted with big category, not a simple case. One case failed, the category failed.

<crupest>Looks like nearly all signal handler related tests failed. I remember there are some problem about signal on Hurd?

<youpi>not really much left

<youpi>possibly it just misuses SIGINFO

<youpi>GNU/Hurd now properly implement SIGINFO except a few fields

<crupest>I think so. Most of failed tests are death check and they check against the message, though I don't know why. Others are mainly related to c++ compiler and std implementation details.

<crupest>Feels easy to fix if adding Hurd platform-specific things to them.

<crupest>I'll continue tomorrow. Really thanks for your help. It is highly helpful to me. You are really nice!

<luckyluke>youpi: what is the status of the glibc test suite on amd64? I'm trying to recompile the deb package with my changes on the signal state but it seems it uses all memory (I have 5G on this vm) during the malloc/tst-malloc-too-large-malloc-check test

<luckyluke>I see a lot of this on gnumach console

<luckyluke>no more room in ffffffffdd6e05e8 ((...bc/elf/ld-x86-64.so.1(2055))

<youpi>there are tests that need a lot of memory yes

<youpi>I usually run it with 6G ram

<youpi>some of the "no room" warnings are expected

<youpi>these are tests that try to push the limits

<youpi>normally with 6G ram the tests pass, except tst-tunables, which I missed x-failing before the 2.40-6 upload

<luckyluke>ok I'll try to increase the memory

<luckyluke>I see really a lot of the "no room" messages, and the test seems stuck for several minutes

<youpi>some tests take a long time yes

<youpi>some time out (and are xfail-ed)

IRC channel logs

2025-02-02.log