Discussion:
Current status
Peter Bex
2006-08-05 20:25:41 UTC
Permalink
Hai all,

The current status is as follows: I checked in my code on the syscall
stuff. This means that currently *PROGRAMS DO NOT WORK*. I'm pretty
confident we can get it to work. Why? Let's see:

When you run, for example, a lstat on a file that exists, it neatly
returns the correct return value (0) and you'll see that errno is set
to 0 as well.

When you run lstat on a file that does NOT exist, it doesn't return -1
as it should, but it returns 2. errno is set to 0!
If you look at libc code, you'll see that in libc/arch/i386/sys/syscall.S
it simply returns the normal eax return value if the carry isn't set.
Otherwise, it calls CERROR. CERROR is defined in
libc/arch/i386/sys/cerror.S, as calling errno, and then SETTING
EAX to -1.

So, it looks like EAX gets set correctly, it just doesn't convert it to -1
and set the errno to EAX. Internally for valgrind everything is kosher
too (the assertion about matching status is not triggered). The only
problem left is figuring out how the hell to get Vex to load up the
carry flag.

I'm trying to get my head around Vex atm, it looks hugely abstracted
and I'm not sure yet how to get some code emitted that will set the
carry flag just after calling int 0x80. This should happen on all
platforms, BTW. The only strange OS is Linux, which doesn't use carry
flags to signal error. They're bitches.

Peter
--
http://sjamaan.ath.cx
--
"The process of preparing programs for a digital computer
is especially attractive, not only because it can be economically
and scientifically rewarding, but also because it can be an aesthetic
experience much like composing poetry or music."
-- Donald Knuth
Kailash Sethuraman
2006-08-22 01:46:46 UTC
Permalink
Hi,
Ok we have the carry flag issue hopefully behind us now.
We can set it correctly, and the 0 length mmap error is fixed.

What remains now is :
- Get memcheck to report malloc/mmap errors correctly.
This is a big task that will require us to look at memcheck and fix
what is required.

- Get the symbol demangling correcty. Errors that have stack traces like
0x12345 ????
0x3355 ????
are useless of course..

Once these two things are ready, we will be in a position to define
missing syscalls and run some proper checks against the code.
I am also quite unsure of how correctly our PRE/POST syscalls report
modified bytes etc to the tool. Fixing memcheck will also probably
take us into this.

Have a nice day,
Kailash
Post by Peter Bex
Hai all,
The current status is as follows: I checked in my code on the syscall
stuff. This means that currently *PROGRAMS DO NOT WORK*. I'm pretty
When you run, for example, a lstat on a file that exists, it neatly
returns the correct return value (0) and you'll see that errno is set
to 0 as well.
When you run lstat on a file that does NOT exist, it doesn't return -1
as it should, but it returns 2. errno is set to 0!
If you look at libc code, you'll see that in libc/arch/i386/sys/syscall.S
it simply returns the normal eax return value if the carry isn't set.
Otherwise, it calls CERROR. CERROR is defined in
libc/arch/i386/sys/cerror.S, as calling errno, and then SETTING
EAX to -1.
So, it looks like EAX gets set correctly, it just doesn't convert it to -1
and set the errno to EAX. Internally for valgrind everything is kosher
too (the assertion about matching status is not triggered). The only
problem left is figuring out how the hell to get Vex to load up the
carry flag.
I'm trying to get my head around Vex atm, it looks hugely abstracted
and I'm not sure yet how to get some code emitted that will set the
carry flag just after calling int 0x80. This should happen on all
platforms, BTW. The only strange OS is Linux, which doesn't use carry
flags to signal error. They're bitches.
Peter
--
http://sjamaan.ath.cx
--
"The process of preparing programs for a digital computer
is especially attractive, not only because it can be economically
and scientifically rewarding, but also because it can be an aesthetic
experience much like composing poetry or music."
-- Donald Knuth
_______________________________________________
Vg4nbsd-devel mailing list
http://bat.berlios.de/mailman/listinfo/vg4nbsd-devel
Loading...