Re: 64bit startup
Luca, le sam. 06 janv. 2024 00:42:35 +0100, a ecrit: > Il 05/01/24 19:12, Sergey Bugaev ha scritto: > > /servers/crash-dump-core crashes on the memset () call in > > hurd:exec/elfcore.c:fetch_thread_fpregset (); the (*fpregs) pointer is > > NULL. The caller passes fpregs = _fpreg, where note.data > > is of type struct elf_lwpstatus, defined in hurd:include/sys/procfs.h, > > whose pr_fpreg field is of type prfpregset_t, which is a typedef to > > fpregset_t, which was an actual struct on i386, but is a pointer on > > x86_64. This would've been easier to debug if I had debuginfo :) > > I had this small patch applied that apparently is enough for me to have some > kind of core dump, I'm not sure if it's a good solution: You probably rather want to fix fetch_thread_fpregset, so as to properly put the floating state into pr_fpreg. This probably needs to actually copy over explicit fields, but that's what we need anyway. > diff --git a/exec/elfcore.c b/exec/elfcore.c > index c6aa2bc8b..405fa8e0c 100644 > --- a/exec/elfcore.c > +++ b/exec/elfcore.c > @@ -544,6 +544,11 @@ dump_core (task_t task, file_t file, off_t corelimit, >note.data.pr_info.si_code = sigcode; >note.data.pr_info.si_errno = sigerror; > > +#ifdef __x86_64__ > + struct _libc_fpstate fpstate; > + memset(, 0, sizeof(fpstate)); > + note.data.pr_fpreg = > +#endif >fetch_thread_regset (threads[i], _reg); >fetch_thread_fpregset (threads[i], _fpreg); > > > HTH > Luca
Re: 64bit startup
Il 04/01/24 10:55, Sergey Bugaev ha scritto: P.S. I have posted all of my patches, so if you're interested in hacking on aarch64-gnu Mach, you should be able to build the full toolchain now. sure, I've started looking into it, but it will take a while before I can run something in userspace. I'm working on top of your gnumach patch for now. Luca
Re: 64bit startup
Il 05/01/24 19:12, Sergey Bugaev ha scritto: /servers/crash-dump-core crashes on the memset () call in hurd:exec/elfcore.c:fetch_thread_fpregset (); the (*fpregs) pointer is NULL. The caller passes fpregs = _fpreg, where note.data is of type struct elf_lwpstatus, defined in hurd:include/sys/procfs.h, whose pr_fpreg field is of type prfpregset_t, which is a typedef to fpregset_t, which was an actual struct on i386, but is a pointer on x86_64. This would've been easier to debug if I had debuginfo :) I had this small patch applied that apparently is enough for me to have some kind of core dump, I'm not sure if it's a good solution: diff --git a/exec/elfcore.c b/exec/elfcore.c index c6aa2bc8b..405fa8e0c 100644 --- a/exec/elfcore.c +++ b/exec/elfcore.c @@ -544,6 +544,11 @@ dump_core (task_t task, file_t file, off_t corelimit, note.data.pr_info.si_code = sigcode; note.data.pr_info.si_errno = sigerror; +#ifdef __x86_64__ + struct _libc_fpstate fpstate; + memset(, 0, sizeof(fpstate)); + note.data.pr_fpreg = +#endif fetch_thread_regset (threads[i], _reg); fetch_thread_fpregset (threads[i], _fpreg); HTH Luca
Re: 64bit startup
Sergey Bugaev, le ven. 05 janv. 2024 21:12:48 +0300, a ecrit: > Also I can't help but notice that the hurd package (i.e the translator > binaries) is still not being built as PIE, This is not actually specific to 64bit. This was set explicitly in 2016 in debian/rules, tests welcome to check whether building the package without it works now. Samuel
Re: 64bit startup
Sergey Bugaev, le ven. 05 janv. 2024 21:12:48 +0300, a ecrit: > I'm not seeing hurd-dbg / hurd-libs-dbg packages in your repo. Yes, my repo is built from the rebootstrap scripts, which drop debug etc. only for creating a booting system. For proper packages, use the usual deb.debian.org debian-ports mirror. Samuel
Bug#1060093: lirc: FTBFS on hurd-i386
Source: lirc
Version: 0.10.2-0.2
Severity: important
Tags: patch
User: debian-hurd@lists.debian.org
Usertags: hurd
X-Debbugs-CC: debian-hurd@lists.debian.org
Hi,
lirc FTBFS on hurd-i386. (Built in the past, last successful build
version was 0.10.1-5.2)
This is due to usage of __u32 (and __u16,__u64) in
include/media/lirc.h, which is not defined on GNU/Hurd. Additionally
inclusion of header files is ifdef-ed and config.h is included.
Moreover, MODINFO is not available on GNU/Hurd since Hurd does not use
modules at all. This change is reflected in the second patch for
debian/rules.
The two patches enabling a successful build on GNU/Hurd (and
GNU/Linux)are attached in next mail:
- include/media/lirc.h
- debian_rules.patch.
I'm sending this bug report to Debian instead of upstream since this
package has been NMU-ed several times, and the second patch is Debian-
specific.
Thanks!
Index: lirc-0.10.2/include/media/lirc.h
===
--- lirc-0.10.2.orig/include/media/lirc.h
+++ lirc-0.10.2/include/media/lirc.h
@@ -6,8 +6,27 @@
#ifndef _LINUX_LIRC_H
#define _LINUX_LIRC_H
+#include "config.h"
+
+#ifdef HAVE_STDINT_H
+#include
+#endif
+
+#ifdef HAVE_LINUX_TYPES_H
#include
+#endif
+
+#ifdef HAVE_LINUX_IOCTL_H
#include
+#endif
+
+#ifdef HAVE_SYS_IOCTL_H
+#include
+#endif
+
+#ifdef __GNU__
+#include
+#endif
#define PULSE_BIT 0x0100
#define PULSE_MASK 0x00FF
@@ -93,55 +112,55 @@
/*** IOCTL commands for lirc driver ***/
-#define LIRC_GET_FEATURES _IOR('i', 0x, __u32)
+#define LIRC_GET_FEATURES _IOR('i', 0x, uint32_t)
-#define LIRC_GET_SEND_MODE _IOR('i', 0x0001, __u32)
-#define LIRC_GET_REC_MODE _IOR('i', 0x0002, __u32)
-#define LIRC_GET_REC_RESOLUTION_IOR('i', 0x0007, __u32)
+#define LIRC_GET_SEND_MODE _IOR('i', 0x0001, uint32_t)
+#define LIRC_GET_REC_MODE _IOR('i', 0x0002, uint32_t)
+#define LIRC_GET_REC_RESOLUTION_IOR('i', 0x0007, uint32_t)
-#define LIRC_GET_MIN_TIMEOUT _IOR('i', 0x0008, __u32)
-#define LIRC_GET_MAX_TIMEOUT _IOR('i', 0x0009, __u32)
+#define LIRC_GET_MIN_TIMEOUT _IOR('i', 0x0008, uint32_t)
+#define LIRC_GET_MAX_TIMEOUT _IOR('i', 0x0009, uint32_t)
/* code length in bits, currently only for LIRC_MODE_LIRCCODE */
-#define LIRC_GET_LENGTH_IOR('i', 0x000f, __u32)
+#define LIRC_GET_LENGTH_IOR('i', 0x000f, uint32_t)
-#define LIRC_SET_SEND_MODE _IOW('i', 0x0011, __u32)
-#define LIRC_SET_REC_MODE _IOW('i', 0x0012, __u32)
+#define LIRC_SET_SEND_MODE _IOW('i', 0x0011, uint32_t)
+#define LIRC_SET_REC_MODE _IOW('i', 0x0012, uint32_t)
/* Note: these can reset the according pulse_width */
-#define LIRC_SET_SEND_CARRIER _IOW('i', 0x0013, __u32)
-#define LIRC_SET_REC_CARRIER _IOW('i', 0x0014, __u32)
-#define LIRC_SET_SEND_DUTY_CYCLE _IOW('i', 0x0015, __u32)
-#define LIRC_SET_TRANSMITTER_MASK _IOW('i', 0x0017, __u32)
+#define LIRC_SET_SEND_CARRIER _IOW('i', 0x0013, uint32_t)
+#define LIRC_SET_REC_CARRIER _IOW('i', 0x0014, uint32_t)
+#define LIRC_SET_SEND_DUTY_CYCLE _IOW('i', 0x0015, uint32_t)
+#define LIRC_SET_TRANSMITTER_MASK _IOW('i', 0x0017, uint32_t)
/*
* when a timeout != 0 is set the driver will send a
* LIRC_MODE2_TIMEOUT data packet, otherwise LIRC_MODE2_TIMEOUT is
* never sent, timeout is disabled by default
*/
-#define LIRC_SET_REC_TIMEOUT _IOW('i', 0x0018, __u32)
+#define LIRC_SET_REC_TIMEOUT _IOW('i', 0x0018, uint32_t)
/* 1 enables, 0 disables timeout reports in MODE2 */
-#define LIRC_SET_REC_TIMEOUT_REPORTS _IOW('i', 0x0019, __u32)
+#define LIRC_SET_REC_TIMEOUT_REPORTS _IOW('i', 0x0019, uint32_t)
/*
* if enabled from the next key press on the driver will send
* LIRC_MODE2_FREQUENCY packets
*/
-#define LIRC_SET_MEASURE_CARRIER_MODE _IOW('i', 0x001d, __u32)
+#define LIRC_SET_MEASURE_CARRIER_MODE _IOW('i', 0x001d, uint32_t)
/*
* to set a range use LIRC_SET_REC_CARRIER_RANGE with the
* lower bound first and later LIRC_SET_REC_CARRIER with the upper bound
*/
-#define LIRC_SET_REC_CARRIER_RANGE _IOW('i', 0x001f, __u32)
+#define LIRC_SET_REC_CARRIER_RANGE _IOW('i', 0x001f, uint32_t)
-#define LIRC_SET_WIDEBAND_RECEIVER _IOW('i', 0x0023, __u32)
+#define LIRC_SET_WIDEBAND_RECEIVER _IOW('i', 0x0023, uint32_t)
/*
* Return the recording timeout, which is either set by
* the ioctl LIRC_SET_REC_TIMEOUT or by the kernel after setting the protocols.
*/
-#define LIRC_GET_REC_TIMEOUT _IOR('i', 0x0024, __u32)
+#define LIRC_GET_REC_TIMEOUT _IOR('i', 0x0024, uint32_t)
/**
* struct
Re: 64bit startup
I'm not seeing hurd-dbg / hurd-libs-dbg packages in your repo. Could you please either teach me where to look, or if they're indeed missing, upload them? Also I can't help but notice that the hurd package (i.e the translator binaries) is still not being built as PIE, unlike basically all the other binaries. This actually helps with debugging for now, but please remember to ensure it does end up as PIE when the system is ready for broader use. /servers/crash-dump-core crashes on the memset () call in hurd:exec/elfcore.c:fetch_thread_fpregset (); the (*fpregs) pointer is NULL. The caller passes fpregs = _fpreg, where note.data is of type struct elf_lwpstatus, defined in hurd:include/sys/procfs.h, whose pr_fpreg field is of type prfpregset_t, which is a typedef to fpregset_t, which was an actual struct on i386, but is a pointer on x86_64. This would've been easier to debug if I had debuginfo :) Sergey
Re: 64bit startup
Samuel Thibault, le jeu. 04 janv. 2024 08:57:51 +0100, a ecrit: > Sergey Bugaev, le mer. 03 janv. 2024 21:56:54 +0300, a ecrit: > > perhaps I need to try two of them in parallel and some I/O-heavy > > workload in the background, as you're saying. > > Yes, that's needed to raise the probability of the bug. > > > Could it be that the two strings are actually different (something > > being wrong with pipes perhaps)? > > I tried > > A=a ; time while /usr/bin/\[ "$A" = a ] ; do A="$(echo -n `echo a` )" ; done > ; echo $A > > The output is empty. But yes, that could be some missing flush or such > in pipes. It happens with dash too. Samuel
Re: 64bit startup
Sergey Bugaev, le ven. 05 janv. 2024 12:06:13 +0300, a ecrit: > > I use > > > > while true ; do apt install --reinstall wdiff ; done > > That did it! I can now reliably reproduce this. > > (I assume you don't mind my box constantly banging on your repo.) It's people.debian.org, it's meant for this :) You can probably also pass to apt an option to keep the donwloaded .deb > > got acd :) > > In the six times that I've reproduced it so far, I got "acd" in all cases. > Hmmm. "interesting" :) Samuel
Re: 64bit startup
On Fri, Jan 5, 2024 at 12:52 AM Samuel Thibault wrote: > Which kind of activity? I just had a loop spawning /bin/true — this should've triggered it assuming it was related to some state getting corrupted on context-switching. > I use > > while true ; do apt install --reinstall wdiff ; done That did it! I can now reliably reproduce this. (I assume you don't mind my box constantly banging on your repo.) > got acd :) In the six times that I've reproduced it so far, I got "acd" in all cases. Hmmm. Sergey
