From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout-p-102.mailbox.org (mout-p-102.mailbox.org [IPv6:2001:67c:2050:0:465::102]) by sourceware.org (Postfix) with ESMTPS id 81ECC3858C53 for ; Sun, 19 Mar 2023 16:44:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 81ECC3858C53 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=orpolo.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=orpolo.org Received: from smtp1.mailbox.org (smtp1.mailbox.org [IPv6:2001:67c:2050:b231:465::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-102.mailbox.org (Postfix) with ESMTPS id 4PfkH73zx4z9sZh; Sun, 19 Mar 2023 17:44:35 +0100 (CET) Message-ID: <97dced9b-9937-a66b-7c6c-d020c0758c4a@orpolo.org> Date: Sun, 19 Mar 2023 17:44:32 +0100 MIME-Version: 1.0 From: Luca Subject: Re: [RFC PATCH 00/34] The rest of the x86_64-gnu port To: Sergey Bugaev , libc-alpha@sourceware.org, bug-hurd@gnu.org Cc: Samuel Thibault References: <20230319151017.531737-1-bugaevc@gmail.com> Content-Language: en-US, it In-Reply-To: <20230319151017.531737-1-bugaevc@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4PfkH73zx4z9sZh X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi Sergey, this looks like a great work! Il 19/03/23 16:09, Sergey Bugaev ha scritto: > I was unable to actually get it running on GNU Mach. It either never gets > started, or crashes soon enough. The latter is actually to be expected, since > the kernel does not actually support i386_fsgs_base_state yet. I was unable > to investigate what exactly happens, because in addition to the troubles with > actually running GNU Mach on qemu-system-x86_64 (-kernel doesn't work..., you > really have to build an image with GRUB) and attaching a debugger to it > (either GDB or QEMU get utterly confused be the switch to the long mode...), > I had troubles with actually spawning the task while breaking on its first > instruction (a la starti). In particular prompt-task-resume didn't seem to > work for me, nor did breaking somewhere before the task should have been > resumed. > > So I would appreciate some help with both testing this patchset (i.e. if you > do have a working x86_64 Mach + userspace setup, build glibc and try to run > it), and some general tips about how I would go about debugging the bootstrap > task from the first instruction onwards with x86_64 GNU Mach, QEMU, and GDB. One reason for troubles in testing with gnumach is that rpc don't work very well yet... Simple syscalls should work if you take my patch with syscall64 v3, and also some simple rpcs, but in general I still see some issues with the 64-bit message format and the mig-generated stubs. I still have most of my tests failing with a 64-bit userspace. That being said, once we have fully working rpcs, I think you could have a "hello-static-glibc" bootstrap module, and assemble a grub rescue disk to test it on gnumach, much like my "hello" test. For this you could also take the commit [0] and add your bootstrap module manually, to reuse the grub disk generation part. Once this works, you should be able to build ext2fs.static, exec.static and run a "hello-dynamic-glibc" test by replacing /hurd/startup, which is the first dynamically-linked executable started. For this case creating a minimal bootable disk is a bit more tricky, I did it once and I should have some scripts that could be reused. In your case you probably need to build a cross-compiler targeting hurd64, maybe with Flavio's scripts (in my tests I use the -ffreestanding environment so I can compile them on GNU/Linux). I'm not sure how this could be optimized for iterative development. About debugging, the nice thing is that you can load the debug symbols of the bootstrap module in the same gdb remote session used to debug gnumach, with: add-symbol-file /module-hello-static-glibc and you can single-step, use breakpoints etc. on both the user and kernel code. For example, you can set a breakpoint on the user entry point _start() and single-step from there. Also, when you attach gdb to qemu, you should avoid setting a breakpoint too early, but anything after setup_main() should be ok. So if you want to set a breakpoint on _start(), I suggest you do it after reaching setup_main(), otherwise it will also stop on gnumach's own _start(), and that will indeed mess up with segmentation and long mode. I hope this helps, Luca [0] https://gitlab.com/luckyd/gnumach/-/commit/cb00d39edc6604cfb485161e85720e23f167d819