|
From: Catalin V. <cat...@ke...> - 2019-07-15 11:59:55
|
My issue is in the following way: I have a mips64 platform and custom ioctl call. Without valgrind the scenario works perfectly, with valgrind it does not. The ioctl handler, as soon as it gets inside the function, it tries to make a switch() statement on the "unsigned int cmd" argument. If I print the argument it shows the case it should go on. But inside the switch statement it goes directly to the default case. I even tried printing the value again in the default case, and it shows it should have gone on that specific case. I think the comparison instruction may load the comparable values with something that is being initialized differently by valgrind when compared to glibc. I tried running with the trace-syscalls, and the cmd argument seems to be set there. I've watched the assembly code in valgrind vs glibc, and they seem a bit different. I've also tried looking at VG_(client_syscall), but this is way upper level. I got to this line that I mentioned previously: dres.jk_StopHere = Ijk_Sys_syscall; I'm trying to get exactly when valgrind catches the parameters sent by the ioctl. >Hi Catalin,> >> I have a bug which I'm trying to narrow down on a mips64 platform.> >Are you seeing a bug in Valgrind or in your application? >If it is in Valgrind, can you descibe it (or even better - create a >Bugzilla ticket)?> >If you believe there is an issue with system calls, you may want to >run Valgrind with --trace-syscalls=yes.> >Regards, >Petar> >On Thu, Jun 27, 2019 at 2:58 PM Catalin Vasile via Valgrind-developers ><valgrind-developers@...> wrote: >> >> Hi, >> >> >> I have a bug which I'm trying to narrow down on a mips64 platform. >> >> For now I'm trying to get to where in valgrind syscall are caught. >> >> Can you pinpoint me to where in the code that happens? >> >> The closest I've got to understanding the call chain so far is this line: >> >> dres.jk_StopHere = Ijk_Sys_syscall; >> >> Found in the following file: >> >> VEX/priv/guest_mips_toIR.c >> >> >> Best regards, >> >> Catalin Vasile >> >> >> _______________________________________________ >> Valgrind-developers mailing list >> Valgrind-developers@... >> https://lists.sourceforge.net/lists/listinfo/valgrind-developers |
|
From: Petar J. <mip...@gm...> - 2019-07-16 12:37:27
|
On Mon, Jul 15, 2019 at 1:24 PM Catalin Vasile <cat...@ke...> wrote: > > My issue is in the following way: > I have a mips64 platform and custom ioctl call. Without valgrind the > scenario works perfectly, with valgrind it does not. > Hi Catalin, I am not sure I follow everything you said in this thread. Can you provide an example that has issues with Valgrind? (even though it will not work on regular mips64 platform, as I understand) Thanks. Regards, Petar |
|
From: Catalin V. <cat...@ke...> - 2019-07-18 14:49:38
|
On 7/16/19 3:37 PM, Petar Jovanovic wrote:
> On Mon, Jul 15, 2019 at 1:24 PM Catalin Vasile
> <cat...@ke...> wrote:
>> My issue is in the following way:
>> I have a mips64 platform and custom ioctl call. Without valgrind the
>> scenario works perfectly, with valgrind it does not.
>>
> Hi Catalin,
>
> I am not sure I follow everything you said in this thread.
>
> Can you provide an example that has issues with Valgrind?
> (even though it will not work on regular mips64 platform, as I understand)
>
> Thanks.
>
> Regards,
> Petar
The kernel module looks like this:
static long unc_char_compat_ioctl(struct file * file, unsigned int cmd,
unsigned long arg)
{
int ret;
pr_emerg("[KCATAH]: unc_char_compat_ioctl() 0x%X\n", cmd);
switch(cmd)
{
case 0x80087800:
{
pr_emerg("[KCATAH]: I have hit a switch case 0x%X\n", cmd);
ret = unc_char_ioctl(file->f_dentry->d_inode, file, cmd, arg);
break;
}
default:
{
pr_emerg("[KCATAH]: things didn't work out 0x%X\n",
(unsigned) cmd);
ret = -EINVAL;
break;
}
}
return ret;
}
The userspace code looks like this:
ret = ioctl(fd, 0x80087800, &req);
If I run the userspace WITHOUT valgrind, it works, the ioctl is succesful.
If I run the userspace WITH valgrind it does NOT work. Here is what the
kernel says at the end of the scenario:
# dmesg | grep KCATAH
[ 802.300246/0] [KCATAH]: unc_char_compat_ioctl() 0x80087800
[ 802.300259/0] [KCATAH]: things didn't work out 0x80087800
#
|
|
From: Petar J. <mip...@gm...> - 2019-08-13 15:00:16
|
Can you check the latest development tree and see if you are seeing the issue with it? There have been some changes related to syscall routines, so there is a (small) chance it could help your issue. Give it a try. Petar |
|
From: Catalin V. <cat...@ke...> - 2019-09-09 12:44:18
|
Hi, I've tried the latest branch, but it does not fix my issue. On 8/13/19 5:59 PM, Petar Jovanovic wrote: > [EXTERNAL] > > Can you check the latest development tree and see if you are seeing > the issue with it? > There have been some changes related to syscall routines, so there is > a (small) chance it could help your issue. > Give it a try. > > Petar |