On Sat, May 6, 2023 at 1:12 PM Sergey Bugaev wrote:
> This is ld.so in the exec server task trying to dir_lookup
> ("/hurd/exec") -- it then crashes ext2fs when it tries to access the
> TCB. But before that, ext2fs starts up, spawns all those
> libports/libpager worker threads (which now start up
Hello,
On Tue, Apr 25, 2023 at 1:59 PM Samuel Thibault wrote:
> Sergey Bugaev, le mar. 25 avril 2023 13:25:02 +0300, a ecrit:
> > @@ -733,6 +734,10 @@ boolean_t thread_invoke(
> >
> > counter(c_thread_invoke_hits++);
> > (void) spl0();
> > +#ifdef
On Tue, May 2, 2023 at 10:04 AM Samuel Thibault wrote:
> I don't see any issue on 32bit gnumach:
>
> $ ./test
> Killed
>
> Perhaps with is only with 64bit gnumach
Yes, most likely it's something 64-bit specific. We know from
experience that the 32-bit gnumach survives a task_terminate call just
Hello,
Sergey Bugaev, le mer. 26 avril 2023 20:33:20 +0300, a ecrit:
> ../kern/ipc_tt.c:395: retrieve_task_self_fast: Assertion
> `task->itk_self != IP_NULL' failed.panic ../kern/debug.c:103:
> Debugger: Debugger invoked, but there isn't one!
>
> This is after typing 'quit' in bc, which calls
Applied, thanks!
Luca Dariz, le mer. 19 avril 2023 21:47:03 +0200, a ecrit:
> * i386/i386/i386asm.sym: add offsets for asm
> * i386/i386/pcb.c: switch FSBASE/GSBASE on context switch and
> implement accessors in thread setstatus/getstatus
> * i386/i386/thread.h: add new state to thread saved
Hi again,
I managed to break gnumach in a new and exciting way (tm):
../kern/ipc_tt.c:395: retrieve_task_self_fast: Assertion
`task->itk_self != IP_NULL' failed.panic ../kern/debug.c:103:
Debugger: Debugger invoked, but there isn't one!
This is after typing 'quit' in bc, which calls exit () --
Sergey Bugaev, le mar. 25 avril 2023 13:25:02 +0300, a ecrit:
> @@ -733,6 +734,10 @@ boolean_t thread_invoke(
>
> counter(c_thread_invoke_hits++);
> (void) spl0();
> +#ifdef __x86_64__
> + wrmsr(MSR_REG_FSBASE,
On Tue, Apr 25, 2023 at 12:02 PM Sergey Bugaev wrote:
> subcode is the address of the fault, and 128 just so happens to be
> 0x80, and %fs:0x80 is of course tcb->reply_port. So it looks like
> fs_base was not restored to its proper value when context-switching to
> the thread, and gets instead
Hello,
I have done some debugging and I think I know what's going on, and it
looks related to this very patch. The device_read_inband () call
actually succeeds, and glibc tries to echo the same thing back (that's
how devstream works, arguably maybe it shouldn't, but whatever); and
when it tries
Sergey Bugaev, le lun. 24 avril 2023 23:27:09 +0300, a ecrit:
> Alternatively, if it is some fatal crash in userland, what should I
> break on in gnumach to detect it? Somewhere in vm_fault.c?
The debug_all_traps_with_kdb variable is there for that, you can also
enable it live from kdb with
Hi,
On Mon, Apr 24, 2023 at 11:02 PM Luca Dariz wrote:
> Il 24/04/23 17:19, Sergey Bugaev ha scritto:
> > Resending without the attachment, because apparently the email did not
> > make it into the list archive so maybe it didn't get to you either;
> > and I'm too conscious about email just
Il 24/04/23 17:19, Sergey Bugaev ha scritto:
Resending without the attachment, because apparently the email did not
make it into the list archive so maybe it didn't get to you either;
and I'm too conscious about email just eating my letters without any
notice or indication since that one time.
Resending without the attachment, because apparently the email did not
make it into the list archive so maybe it didn't get to you either;
and I'm too conscious about email just eating my letters without any
notice or indication since that one time. If you didn't get the last
one and still want
Sergey Bugaev, le sam. 22 avril 2023 15:11:30 +0300, a ecrit:
> So please suggest your favorite REPL :)
bc ? :)
Samuel
On Sat, Apr 22, 2023 at 2:17 PM Luca Dariz wrote:
> Hi Sergey,
Hi,
> Il 20/04/23 13:51, Sergey Bugaev ha scritto:
> > On Wed, Apr 19, 2023 at 11:52 PM Sergey Bugaev wrote:
> > We do reach the call to __thread_set_state (), but then it uses
> > __mig_memcpy (), which is just 'return memcpy
Hi Sergey,
Il 20/04/23 13:51, Sergey Bugaev ha scritto:
On Wed, Apr 19, 2023 at 11:52 PM Sergey Bugaev wrote:
We do reach the call to __thread_set_state (), but then it uses
__mig_memcpy (), which is just 'return memcpy (...)'. And (because of
the static build?), that memcpy () is the full
Sergey Bugaev, le ven. 21 avril 2023 17:30:12 +0300, a ecrit:
> On Fri, Apr 21, 2023 at 12:24 PM Samuel Thibault
> wrote:
> > No, they don't :) otherwise they wouldn't respect the ABI. The AMD64
> > ABI indeed defaults to /lib/ld64.so.1, and says that Linux uses
> > /lib64/ld-linux-x86-64.so.2,
On Fri, Apr 21, 2023 at 12:24 PM Samuel Thibault
wrote:
> No, they don't :) otherwise they wouldn't respect the ABI. The AMD64
> ABI indeed defaults to /lib/ld64.so.1, and says that Linux uses
> /lib64/ld-linux-x86-64.so.2, and that is cast in stone, we cannot change
> it any more.
>
>
Sergey Bugaev, le ven. 21 avril 2023 12:17:54 +0300, a ecrit:
> Hello,
>
> On Fri, Apr 21, 2023 at 12:01 AM Samuel Thibault
> wrote:
> > BTW, which dynamic linker path do we have set for x86_64-gnu?
>
> It's in gcc/config/i386/gnu64.h in GCC tree:
>
> #define GNU_USER_DYNAMIC_LINKER64
Hello,
On Fri, Apr 21, 2023 at 12:01 AM Samuel Thibault
wrote:
> BTW, which dynamic linker path do we have set for x86_64-gnu?
It's in gcc/config/i386/gnu64.h in GCC tree:
#define GNU_USER_DYNAMIC_LINKER64 "/lib/ld-x86-64.so.1"
It was added by Flavio.
So GCC passes -dynamic-linker
Hello,
Sergey Bugaev, le jeu. 20 avril 2023 16:08:45 +0300, a ecrit:
> Is that actually configurable somewhere (at gcc/binutils build time, I
> mean)?
It's probably in the link script, somewhere in
/usr/lib/*/ldscripts/elf*x86_64*
> I'm thinking we will want to map the lower 4GB of address
FWIW, mach-bootstrap-hello is supposed to then echo back what you type
on the console, but it doesn't work. From some debugging, it seems
that once I input something, the following device_write () call hangs
here:
(gdb)
ast_taken () at ../kern/ast.c:88
88 if (reasons & AST_NETWORK)
(gdb)
96 if
Il 20 aprile 2023 13:18:29 UTC, Sergey Bugaev ha scritto:
>On Thu, Apr 20, 2023 at 4:08 PM Sergey Bugaev wrote:
>> > Would it work for you to shrink temporarily the VM space, at least for
>> > testing?
>>
>> Yeah, that's also what I've been thinking to try out next. I'm
>> somewhat surprised
Sergey Bugaev, le jeu. 20 avril 2023 16:18:29 +0300, a ecrit:
> On Thu, Apr 20, 2023 at 4:08 PM Sergey Bugaev wrote:
> > > Would it work for you to shrink temporarily the VM space, at least for
> > > testing?
> >
> > Yeah, that's also what I've been thinking to try out next. I'm
> > somewhat
On Thu, Apr 20, 2023 at 4:01 PM Luca wrote:
> There is likely some limitation in the pmap module in gnumach, IIRC it should
> statically allocate the user L3 page tables as long as the limit is below the
> first 512GB, but I never really tested it yet.
That sounds plausible, yes, I've seen
Il 20 aprile 2023 12:46:51 UTC, Sergey Bugaev ha scritto:
>On Thu, Apr 20, 2023 at 3:33 PM Samuel Thibault
>wrote:
>> Sergey Bugaev, le jeu. 20 avril 2023 15:27:15 +0300, a ecrit:
>> > On Thu, Apr 20, 2023 at 3:08 PM Samuel Thibault
>> > wrote:
>> > > > > See
On Thu, Apr 20, 2023 at 3:33 PM Samuel Thibault wrote:
> Sergey Bugaev, le jeu. 20 avril 2023 15:27:15 +0300, a ecrit:
> > On Thu, Apr 20, 2023 at 3:08 PM Samuel Thibault
> > wrote:
> > > > > See 56010b73e81e2cb1082e418699f98353598fe671 and its __mig_memcpy.
> > > >
> > > > Interesting; but
Sergey Bugaev, le jeu. 20 avril 2023 15:27:15 +0300, a ecrit:
> On Thu, Apr 20, 2023 at 3:08 PM Samuel Thibault
> wrote:
> > > > See 56010b73e81e2cb1082e418699f98353598fe671 and its __mig_memcpy.
> > >
> > > Interesting; but that one's dealing with the SHARED case, isn't it?
> >
> > Yes but I
On Thu, Apr 20, 2023 at 3:08 PM Samuel Thibault wrote:
> > > See 56010b73e81e2cb1082e418699f98353598fe671 and its __mig_memcpy.
> >
> > Interesting; but that one's dealing with the SHARED case, isn't it?
>
> Yes but I guess it fixed the static case too?
We must be talking past each other --
Sergey Bugaev, le jeu. 20 avril 2023 15:05:25 +0300, a ecrit:
> On Thu, Apr 20, 2023 at 2:56 PM Samuel Thibault
> wrote:
> >
> > Hello,
> >
> > Sergey Bugaev, le jeu. 20 avril 2023 14:51:04 +0300, a ecrit:
> > > Why was this not an issue for us on i386?
> >
> > See
On Thu, Apr 20, 2023 at 2:56 PM Samuel Thibault wrote:
>
> Hello,
>
> Sergey Bugaev, le jeu. 20 avril 2023 14:51:04 +0300, a ecrit:
> > Why was this not an issue for us on i386?
>
> See 56010b73e81e2cb1082e418699f98353598fe671 and its __mig_memcpy.
Interesting; but that one's dealing with the
Hello,
Sergey Bugaev, le jeu. 20 avril 2023 14:51:04 +0300, a ecrit:
> Why was this not an issue for us on i386?
See 56010b73e81e2cb1082e418699f98353598fe671 and its __mig_memcpy.
> VM_MAX_USER_ADDRESS, which is defined to VM_MAX_ADDRESS, which is then
> defined to 0xc000, same as on i386.
On Wed, Apr 19, 2023 at 11:52 PM Sergey Bugaev wrote:
> On Wed, Apr 19, 2023 at 10:48 PM Luca Dariz wrote:
> > * i386/i386/pcb.c: switch FSBASE/GSBASE on context switch and
> > implement accessors in thread setstatus/getstatus
> > * i386/i386/thread.h: add new state to thread saved state
> > *
On Wed, Apr 19, 2023 at 10:48 PM Luca Dariz wrote:
> * i386/i386/pcb.c: switch FSBASE/GSBASE on context switch and
> implement accessors in thread setstatus/getstatus
> * i386/i386/thread.h: add new state to thread saved state
> * kern/thread.c: add i386_FSGS_BASE_STATE handler
Hi Luca -- this
34 matches
Mail list logo
