bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Valgrind port to Hurd


From: Athul M A
Subject: Re: Valgrind port to Hurd
Date: Sun, 10 Mar 2019 14:35:41 +0530

Sir,
I have almost fixed errors and configured valgrind to state where I think its time to start the porting of Mach traps and the RPC handler. My observation is that we need to handle mach traps in a way similar to what the other operating systems do theirs and RPCs using a new specific handler. Could you guide me through the process and exactly how these fit into valgrind?

Since we use RPCs in GNU Hurd, Will it be okay if we call them directly after we do the preprocessing valgrind does? Or should we make the call in a way it is implemented(using mach_msg_traps)? Reason why I felt this doubt is because in the implementation for other distributions, system calls are done using assembly code and not using glibc equivalents.


On Sat, Feb 9, 2019 at 6:51 PM Samuel Thibault <address@hidden> wrote:
Hello,

(btw, it'd probably be useful to keep the address@hidden list in Cc so
people know about the progress, and more importantly, can help you too,
otherwise you'll be dependent on my free time, which is scarse)

Athul M A, le ven. 08 févr. 2019 13:40:02 +0530, a ecrit:
> I was able to build Valgrind from the code you provided after fixing the errors
> in the compilation and ignoring tests.

Good :)

> I tried running the Valgrind executable but it exits with a message
> "Killed". When I tried to debug it using gdb, it stops execution,
> even before the first step, with a message "Unknown signal" and error
> appears to be in m_debuglog.c . I was not able to add breakpoints
> either. It returned "Cannot insert breakpoint, Cannot access memory at
> .." . Can you help me with this? Also what should be my next step?

I don't think gdb will be useful in general in the context of valgrind,
because valgrind will probably never behave the way gdb expects.

You'd probably go better with booting the gnumach-image-1.8-486-dbg
kernel so that the output of mach_print("foo") gets printed on the
gnumach console. Then you can debug with it since it can be easily
called from anywhere.

asm (".global mach_print;"
     " mach_print:;"
     " mov $0xffffffe2, %eax;"
     " lcall $0x7, $0x0;"
     " ret;");

Samuel

reply via email to

[Prev in Thread] Current Thread [Next in Thread]