On Sat, Jan 6, 2024 at 2:42 AM Luca <l...@orpolo.org> wrote: > 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:
> +#ifdef __x86_64__ > + struct _libc_fpstate fpstate; > + memset(&fpstate, 0, sizeof(fpstate)); > + note.data.pr_fpreg = &fpstate; > +#endif > fetch_thread_regset (threads[i], ¬e.data.pr_reg); > fetch_thread_fpregset (threads[i], ¬e.data.pr_fpreg); Well, that should surely prevent the crash, but so will commenting out the fetch_thread_fpregset call completely (perhaps this is what we should actually do for the time being). note.data is what we're writing out into the ELF core dump file; it doesn't make any sense for it to be a pointer to a stack-allocated variable in the dumper's address space. It doesn't make much sense for it to be a pointer at all. We need to figure out what kind of note GDB expects there to be, and write that out. It doesn't necessarily have to match our definition of fpregset_t; in fact I think it'd be better if builds of GDB without any explicit support for x86_64-gnu would be able to read our core files. And this means copying what Linux does, instead of apparently Solaris, as the current elfcore tries to. Doing this might fix issues with reading core files on i686-gnu, too. > sure, I've started looking into it, \o/ > but it will take a while before I > can run something in userspace. Sure, I don't expect you to produce a working kernel overnight :) I kind of want to participate in kernel-side hacking too, but I don't nearly have the understanding required. How does initial boot protocol work, for example? I mean, where and how control is transferred, what gets passed in registers, that kind of thing. I've found many detailed explanations of board-specific boot details (e.g. for Raspberry Pi 3), and [0] has a nice explanation of how to make U-Boot load a custom kernel instead of Linux. I haven't been able to find much info on GRUB; it sounds like Multiboot still exists on AArch64, but it's unclear exactly how it works. [0]: https://krinkinmu.github.io/2023/08/21/how-u-boot-loads-linux-kernel.html Then, we're supposed to parse & use the device tree, aren't we? Do I understand it right that both Mach and userland would have to deal with the device tree? — in case of Mach, this would be needed to get info on CPU cores, RAM, and serial / console / UART, right? Do the questions at least make sense? Or am I talking nonsense? Can you recommend any useful resources? Are you targeting (or: do you think it's realistic to target) many platforms / boards in a generic manner, or would we have to have platform-specific gnumach builds? Does it make sense to start with some specific platform (qemu "virt"?), and expand from there, or is it better to build in the genericity from the start? Sergey