Sergey Bugaev, le mar. 11 avril 2023 00:24:55 +0300, a ecrit:
> On Mon, Apr 10, 2023 at 10:20 PM Samuel Thibault
> wrote:
> >
> > Sergey Bugaev, le dim. 19 mars 2023 18:09:43 +0300, a ecrit:
> > > As for sigreturn specifically: I'm concerned about the possibility that
> > > putting the register du
On Mon, Apr 10, 2023 at 10:20 PM Samuel Thibault
wrote:
>
> Sergey Bugaev, le dim. 19 mars 2023 18:09:43 +0300, a ecrit:
> > As for sigreturn specifically: I'm concerned about the possibility that
> > putting the register dump onto the user's stack (or at %rsp - 128, on
> > x86_64)
> > may clobbe
Hello,
Sergey Bugaev, le dim. 19 mars 2023 18:09:43 +0300, a ecrit:
> As for sigreturn specifically: I'm concerned about the possibility that
> putting the register dump onto the user's stack (or at %rsp - 128, on x86_64)
> may clobber the data trampoline.c puts there (unless an altstack is used),
Hello,
Thanks for this series!
I have pushed a first batch of commits, will review the rest later.
Samuel
Il 21/03/23 15:38, Sergey Bugaev ha scritto:
But how does a core know its CPU number?
Currently through the APIC_ID register, see the CPU_NUMBER macro in
i386/i386/cpu_number.h.
This would've been easier if we could pass the port name as an env
variable, then we could pick some predefined n
On Tue, Mar 21, 2023 at 6:33 PM Almudena Garcia
wrote:
> > But how does a core know its CPU number?
>
> Calling cpu_number() function, or getting its APIC ID from its Local APIC
Ah.
That's too hardware-y for me to understand; but I see that cpu_number
() in i386/i386/cpu_number.c also uses apic,
On Tue, Mar 21, 2023 at 5:19 PM Luca wrote:
> > Every thread needs to have its own values of fs_base / gs_base, and
> > you need to store/restore them on context switch by accessing the
> > appropriate MSR. There's also the swapgs instruction that I'm told is
> > useful if you also use gs for kern
On Tue, Mar 21, 2023 at 5:19 PM Luca wrote:
> > Every thread needs to have its own values of fs_base / gs_base, and
> > you need to store/restore them on context switch by accessing the
> > appropriate MSR. There's also the swapgs instruction that I'm told is
> > useful if you also use gs for kern
Il 21/03/23 14:03, Sergey Bugaev ha scritto:
Ah, so you're saying the com port works, but VGA console (or whatever
it's called, I don't have a clue about hardware as you might have
noticed...) support is buggy? That makes sense, I will try com0, thank
you!
I suppose, yes, it might also be x86_6
On Tue, Mar 21, 2023 at 3:52 PM Luca wrote:
>
> Il 21/03/23 13:37, Sergey Bugaev ha scritto:
> > On Tue, Mar 21, 2023 at 3:20 PM Luca wrote:
> >> did you add $(task-resume) in the boot script?
> >
> > $(prompt-task-resume), yes.
> >
> > But (see my later mail) Mach hits a page fault trying to pri
Il 21/03/23 13:37, Sergey Bugaev ha scritto:
On Tue, Mar 21, 2023 at 3:20 PM Luca wrote:
did you add $(task-resume) in the boot script?
$(prompt-task-resume), yes.
But (see my later mail) Mach hits a page fault trying to printf "task
loaded:", it never gets to resuming the task. This must be
On Tue, Mar 21, 2023 at 3:20 PM Luca wrote:
> did you add $(task-resume) in the boot script?
$(prompt-task-resume), yes.
But (see my later mail) Mach hits a page fault trying to printf "task
loaded:", it never gets to resuming the task. This must be due to some
difference in how we're running QE
Il 21/03/23 11:28, Sergey Bugaev ha scritto:
On Tue, Mar 21, 2023 at 12:48 PM Luca wrote:
Great! if you still have issues with the long mode, you could try to
hack gnumach to wait at some point (e.g. user_bootstrap() or
setup_main()), attach with gdb and then continue. Either with some delay
or
On Tue, Mar 21, 2023 at 2:04 PM Sergey Bugaev wrote:
> It seems to parse the bootscript correctly. It starts the initial
> thread, which loads the ELF and then hangs right here (on printf???):
>
>
>
> Does that ring any bells?
Maybe this will shed some light:
(gdb) s
charput (pos=3840, ch=116 '
On Tue, Mar 21, 2023 at 1:28 PM Sergey Bugaev wrote:
>
> On Tue, Mar 21, 2023 at 12:48 PM Luca wrote:
> > Great! if you still have issues with the long mode, you could try to
> > hack gnumach to wait at some point (e.g. user_bootstrap() or
> > setup_main()), attach with gdb and then continue. Eit
Il 21/03/23 10:11, Sergey Bugaev ha scritto:
Can you attach with gdb at this point? IIRC you can also dynamically
enable/disable the gdb server through the qemu monitor, or stop and see
the registers from there.
Sure:
(gdb) target rem :1234
Remote debugging using :1234
warning: Remote gdbserve
On Tue, Mar 21, 2023 at 11:36 AM Luca wrote:
>
> Il 20/03/23 20:10, Sergey Bugaev ha scritto:
> > I've gone through the process again (without GDB, even, for now).
> > Attaching two screenshots: the first one shows what I input to GRUB
> > (seemingly all correct?), on the second one Mach boots, pr
Il 20/03/23 20:10, Sergey Bugaev ha scritto:
I've gone through the process again (without GDB, even, for now).
Attaching two screenshots: the first one shows what I input to GRUB
(seemingly all correct?), on the second one Mach boots, prints "1
bootstrap modules" and... just sits there doing noth
On Sun, Mar 19, 2023 at 11:13 PM Luca wrote:
> > How do you even attach gdb to qemu properly without racing against
> > Mach starting up? qemu -S doesn't work (unlike on i386), since if you
> > attach GDB immediately at startup, it freaks out about some message
> > size mismatch, apparently relate
Nice work indeed Sergey!
On Sun, Mar 19, 2023 at 12:44 PM 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 gets
> > started, or crashes soon enough. The latter is a
Il 19/03/23 18:39, Sergey Bugaev ha scritto:
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.
Actually no, exec is the first dynamic executable alrea
(un-cc-ing libc-alpha)
> 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-ge
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
Hello!
(Naturally, the subject line is a reference to the "How to draw an owl" meme.)
It's been more than a month since I've tried to run ./configure
--host=x86_64-gnu and see what would come out of it, and here we are now:
with these patches, glibc fully builds, and even somewhat "works"!
On te
24 matches
Mail list logo
