From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yb1-xb31.google.com (mail-yb1-xb31.google.com [IPv6:2607:f8b0:4864:20::b31]) by sourceware.org (Postfix) with ESMTPS id C857B3858C2B for ; Mon, 20 Mar 2023 05:03:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C857B3858C2B Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-yb1-xb31.google.com with SMTP id p204so440930ybc.12 for ; Sun, 19 Mar 2023 22:03:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1679288623; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=0DO0DHzuKVj1jSGLOtbgT/kH6n4hN2qCMg3KqLzBzVQ=; b=QTCp/PLdfx3W65JhPX0MU66TKf35mAjc6Xq05sT/Xd2dK9Z5/jVh16wbW1f6ehNRb1 nuI2L4Fx8RwGGip8dmhLBLWu8Xu3Tl2qIlDc86j2YjkABQ1Xs3fBP92OsJ/49Ex+zroj bNKI4weJLONVkDjboYIpJ3sczQvhNTvTQL1Qz0+IwBNIgUG8Sw3RhrxP67GMpu1zpPqS brkBEi5OgTRgJVkVEdAQwCMKIVA2SOQfp0G8iGa1ZVRsn6yDtbI6tiJXejEZnh7wCmgy zcLZJDcS+73Ivt9Yv8dyBUXA9jyon5Oirbx9cZ3N66KcxZQbFXRu2xmq0z5oVipXiajY cftg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679288623; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=0DO0DHzuKVj1jSGLOtbgT/kH6n4hN2qCMg3KqLzBzVQ=; b=zIV9k22R9QwwPcdpWC1mVdWPpyWr0avf3o9nZ8591t7LXsOKlpOuKQKlqZbVKfc7cG TnjiBM1ZiukXZQgH9+hrR3zRHoDyIp2exvLj8NzNlKfa3Tn0V1KqlVM2tIzOHxSV031F al3SifDE2vx67Mwvat5eHRkQbeXSO1VEK2VRONPHUR6i/gcCvPzToSirisFSwbLd7asX 33b4Xh+MT8/JeVrDRLvUk+PCKU/Jt2H76ibp9vxFntfN0bHa0SK/Ig9LCg/gOFb46jJH rQcGTCpzSiZ+cr+zRDJP1vzxf8ZwT658W1e8zaS1tYELg+hiYDgrlwxaoyODt7wpBAwS vd4Q== X-Gm-Message-State: AO0yUKXsENlEgmvdTOH6hQHBaKYGTxazOr+yCCus3tl4il9tTM68oz73 vKyz9lqfWC6IuS0LPlQQKYLArZy6M8Vpzu8mmw== X-Google-Smtp-Source: AK7set8eX3dI9ADw+DozNUYlyiHYy+yX0Du/HM9nuRnwA+zc+15xxkJssushHxir926aIc8zXLNcac9XeWHa/kFrdr4= X-Received: by 2002:a05:6902:150e:b0:af6:9419:60bc with SMTP id q14-20020a056902150e00b00af6941960bcmr6222450ybu.0.1679288623213; Sun, 19 Mar 2023 22:03:43 -0700 (PDT) MIME-Version: 1.0 References: <20230319151017.531737-1-bugaevc@gmail.com> <97dced9b-9937-a66b-7c6c-d020c0758c4a@orpolo.org> In-Reply-To: <97dced9b-9937-a66b-7c6c-d020c0758c4a@orpolo.org> From: =?UTF-8?B?RmzDoXZpbyBDcnV6?= Date: Mon, 20 Mar 2023 01:03:32 -0400 Message-ID: Subject: Re: [RFC PATCH 00/34] The rest of the x86_64-gnu port To: Luca Cc: Sergey Bugaev , libc-alpha@sourceware.org, bug-hurd@gnu.org, Samuel Thibault Content-Type: multipart/alternative; boundary="000000000000dcb16b05f74dd9a0" X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: --000000000000dcb16b05f74dd9a0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Nice work indeed Sergey! On Sun, Mar 19, 2023 at 12:44=E2=80=AFPM Luca wrote: > 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 ge= ts > > 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. > I tested with your syscall64 v3. It seems most programs do not work because the user stack is not aligned correctly. I sent a patch to align it to 16 bytes (seems like that's what most other OSes use nowadays) and that fixed a bunch. > > 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/cb00d39edc6604cfb485161e85720e= 23f167d819 > --000000000000dcb16b05f74dd9a0--