IRC channel logs

<gnu_srs1>Hi, seems like Built package are not uploaded:See Built link at https://buildd.debian.org/status/architecture.php?a=hurd-i386&suite=sid

<gnu_srs1>BTW: HNY :)

<youpi1>ah yes cron was down, I have restarted it

<youpi1>thanks

<gnu_srs1>Hi. Regarding the page fault when trying to boot the cross-built Hurd: start ext2fs: kernel: Page fault (14), code=4; Stopped at 0x80ef97f: movl 0x18(%ecx),%eax

<gnu_srs1>addr2line -e /tools/hurd/ext2fs.static 0x80ef97f;.../tmp/src/glibc-2.36/hurd/../mach/lock-intern.h:60

<gnu_srs1>#if defined __USE_EXTERN_INLINES && defined _LIBC; _EXTERN_INLINE void __spin_lock (__spin_lock_t *__lock)

<gnu_srs1>{ __lll_lock (__lock, 0); <- line 60};#endif

<gnu_srs1>Any ideas?

<youpi1>without the whole backtrace, no

<youpi1>note that for gnumach to get the whole backtrace, you need to use CFLAGS=-fno-omit-frame-pointer

<youpi1>otherwise it's hard to unwind the stack

<gnu_srs1>Would this patch have any effect? patches/hurd-i386/tg-thread-cancel.diff

<youpi1>only the jmp-unwind.c would possibly have effect

<youpi1>having the whole backtrace would tell if it's involved

<youpi1>also, simply testing would tell

<youpi1>actually, no, the jmp-unwind part would not be affected by the patch

<youpi1>in all cases it's an assert that you would get

<gnu_srs1>As a reference: replacing ext2fs.static with the one built on Debian, all is fine. Is it sufficient to rebuild gnumach with the added flag?

<youpi1>gnu_srs1: no, it's the backtraced code that needs to be rebuilt, so glibc+hurd

<gnu_srs1>Hi again, now I have a backtrace: https://paste.debian.net/1265942/

<gnu_srs1>How to know which processes the other addresses are from?

<youpi1>a backtrace is always from one given process only

<youpi1>since it's the call stack on one single stack

<youpi1>it might also be interesting to trace/tu $task2

<youpi1>now that I actually get your whole output...

<youpi1>Stopped at 0x811b658: movl %gs:0x14,%esi

<youpi1>that looks very much like the static pie issue

<youpi1>see patch git-static-pie.diff

<youpi1>af6b1cce9812273c7f597be6536d28eaec6fb89b in upstream

<gnu_srs1>trace/tu $task2; Bad thread address 0xf5980d80

<youpi1>ah yes sorry it needs to be given the thread address: trace/tu $task2.0

<youpi1>but really the static pie patch is very much likely to fix that

<gnu_srs1>trace/tu $task2.0;Continuation thread_bootstrap_return;>>>>> user space <<<<<;0x801b9a0()

<gnu_srs1>Thanks anyway, I'll rebuild with that patch.

<gnu_srs1>I have the following two lines in glibc-site.hurd-i386 since before: libc_cv_cc_pie_default=yes; libc_cv_pic_default=yes Are they really needed?

<youpi1>probably not

<gnu_srs1>Thank for your help, but it seems like the problem persists: https://paste.debian.net/1265955/

<youpi1>it's not the same problem

<youpi1>see the instruction, it's not the same

<youpi1>faccessat, you may need the local-no-bootstrap-fs-access patches

IRC channel logs

2022-12-31.log