|
From: Tom H. <to...@co...> - 2005-03-30 16:08:47
|
In message <200...@ac...>
Julian Seward <js...@ac...> wrote:
>> > Tom, perhaps you could generate some patches and post them to the list
>> > to see how they turn out. It will be interesting to see how much libc
>> > stuff is platform-specific.
>>
>> Attached is a first cut at a kernel abstraction layer. It removes
>> most of the direct system calls from the coregrind directory and
>> moves them into KAL routines. As a side effect it implements the
>> missing mylibc functionality for amd64.
>
> That looks like an excellent start. Does it compile/build on both
> x86 and amd64?
It does now - the version I sent before had a few minor issues
on x86 but I've just fixed them.
>> I've made a start on removing VKI types from the KAL interface as
>> any abstraction layer will need to be independent of the types used
>> to communicate with the kernel. Many routines still use VKI types
>> in their interface however.
>
> I guess kal basically implements a tiny subset of libc functionality.
> We need to consider a way to deal with returning error values.
> Currently those functions return -1 if there's a problem, but:
>
> * that precludes them returning -1 as a legitimate return value
>
> * having -1 as the only return value may not give enough detail
> for the caller to diagnose an error return and take appropriate
> action
>
> Not sure how to fix this. We could copy the libc madness and have
> an errno which gets set with a value indicating the problem.
> Or we could give all kal functions an Int* first parameter into
> which an error value is written if there is an error.
Yep, the whole question of error codes was another thing that was
a bit thorny when I was doing it. I mostly tried to push the is_kerror
tests down into KAL but some of them are still outside which is wrong.
I agree that we really want out of band error reporting, which means
either reserving the return value for the error and returning any
other values through reference arguments, or adding an error argument
to each routine, or using a global.
> In either case we'd need an kal-specific enum holding error codes
> (KAL_EINVAL, KAL_EBADF, etc), and, for each target, a function
> which converts kernel return values for the target into KAL_E*
> values.
Sounds about right. Error codes presumably have to be in the tool
visible header, along with any structures that tool visible functions
want to use in their interface.
>> I think we should just use the libc API for this, if not the system
>> glibc.
>
> Yes. The above suggestion effectively enshrines that, modulo
> perhaps sidestepping the errno uglyness for returning error codes.
Well the other thing that I did for several routines was to use
a simpler interface that didn't rely on kernel structures, so for
example gettimeofday just returns a ULong and nanosleep takes a
ULong rather than faffing about with a structure.
Likewise for getrlimit/setrlimit which were the other ones where I
made an attempt to remove VKI types from the interface.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|