lkml.org 
[lkml]   [1998]   [Feb]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: small bug in memory_lseek()
Hi Dave,

> In memory_lseek() in drivers/char/mem.c, the code to stop successful
> seeks on negative offsets giving what look like error returns (as
> described in the comment) is never reached. A patch to fix this
> follows.

I checked the source of strace 3.1.0.1, and it doesn't even check the
return value of lseek, so strace doesn't care.

I also checked gdb. I have a program that filters the system calls
made by gdb and feeds it spoofed return values from ptrace. So I
happen to know that linux gdb, at least on my system, does not use
lseek/read to read its child process memory.

However, anyone working on gdb will need to change the gdb procfs code
if they ever enable it for Linux. In gdb 4.16, file gdb/procfs.c,
function procfs_xfer_memory, I see a call to lseek:

if (lseek(pi->fd, (off_t) memaddr, 0) == (off_t) memaddr)

I believe that if gdb were enabled to use procfs on Linux,
it would rely on the existing negative-return-value-for-negative-argument
semantics.

I don't know who the right person is to tell this too but I just
wanted to raise a concern. Does anyone know who takes care of
gdb for linux?

Regards,

Michael Chastain
<mailto:mec@shout.net>
"love without fear"

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu

\
 
 \ /
  Last update: 2005-03-22 13:41    [W:0.062 / U:0.048 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site