IRC channel logs


back to list of logs

<gnu_srs1>Hi, seems like Built package are not uploaded:See Built link at
<gnu_srs1>BTW: HNY :)
<youpi1>ah yes cron was down, I have restarted it
<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:
<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:
<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