Re: [Valgrind-users] Syscall/ioctl wrappers

[Subhashish P. <sp...@gm...>]

Hello again!

Ok when I add case 0x5309: at line 5500 and build valgrind again and
run the eject under it, it gives me this:

sprkv5@cb-4440s:~$ valgrind ./eject
==29522== Memcheck, a memory error detector
==29522== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==29522== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info
==29522== Command: ./eject
==29522==
==29522==
==29522== HEAP SUMMARY:
==29522==     in use at exit: 0 bytes in 0 blocks
==29522==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==29522==
==29522== All heap blocks were freed -- no leaks are possible
==29522==
==29522== For counts of detected and suppressed errors, rerun with: -v
==29522== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 2)

But I have some more questions -

1 - It was mentioned "it may well be that no memory is read/written,
but you'd have to look at the kernel and see what that ioctl does to
be sure." Does it mean using strace or looking at kernel logs using
dmesg?

2 - These ARG1, ARG2 and ARG3 in that source - what's their relation
to the syscall that's being wrapped?

3 - The PRINT(), PRE_MEM_READ(), PRE_REG_READ(), POST_MEM_WRITE  -
where in the source is their definition? I need to understand what
they do - I get the context that they are the read/write primitives of
valgrind or am I wrong here?

4 - I would be  porting valgrind to GNUMach based Hurd - so I'd have
to handle RPCs there, so basically I'd need to implement
syswrap-platform.c, and maybe syscall-platform.S, am I right?

5 - What's the speciality about the syscall-platform.S - why's it so
"magical" as referred in syswrap-main.c?

Regards,
Subhashish Pradhan


On Mon, Mar 24, 2014 at 2:10 PM, Tom Hughes <to...@co...> wrote:
> On 24/03/14 07:09, Subhashish Pradhan wrote:
>
>> The eject.c example provided here at http://leapster.org/linux/cdrom/
>> will compile successfuly
>> with a #include <stdlib.h>. Then when run it under as "valgrind
>> ./eject', it still reports:
>>
>> ==6212== Command: ./eject
>> ==6212==
>> ==6212== Warning: noted but unhandled ioctl 0x5309 with no size/direction
>> hints
>> ==6212==    This could cause spurious value errors to appear.
>> ==6212==    See README_MISSING_SYSCALL_OR_IOCTL for guidance on
>> writing a proper wrapper.
>>
>> Why would that be? (since ioctls are wrapped in
>> coregrind/m_syswrap/syswrap-linux.c)
>
>
> The ioctl system call in general is wrapped, but it doesn't know about every
> single ioctl, so you may need to teach it. If you read the file it mentions
> in the message you will find some hints, especially in the final section
> about ioctls.
>
>
>> What is this "ioctl 0x5309 with no size/redirection hints" and how
>> could that be solved
>> by PRE or POST functions?
>
>
> Because the ioctl number can encode the size and direction of memory access
> valgrind can sometimes guess at how much memory will be read or written by a
> system call.
>
> Not all ioctls actually make use of that facility though, and even when they
> do it may not be right, so valgrind has specific wrappers for many ioctls to
> make sure we do the right thing.
>
>
>> Or specifically, I couldn't understand the 0x5309 operation code
>> context as explained in this post on this mailing list below:
>>
>> <http://valgrind.10908.n7.nabble.com/noted-but-unhandled-ioctl-0xae03-with-no-size-direction-hints-tp38957p38959.html>
>
>
> Add it to the switch statement in the ioctl wrappers, with appropriate calls
> to indicate how much memory is read/written.
>
> In this case, and assuming that ioctl triggers the eject, it may well be
> that no memory is read/written, but you'd have to look at the kernel and see
> what that ioctl does to be sure.
>
> Tom
>
> --
> Tom Hughes (to...@co...)
> http://compton.nu/