I am using Red Hat sources, which has function open_kcore() hardcoded to
return -EPERM always.
Changing this function to the way it is defined in the public sources (as
shown below) did the trick.
open_kcore(struct inode * inode, struct file * filp)
{
return capable(CAP_SYS_RAWIO) ? 0 : -EPERM;
}
I am now able to use gdb to examine kernel symbols.
Uma.
Quoting UmaMaheswari Devi <[email protected]>:
I am new to kernel hacking and am facing problems in tryingstatic int
to peek at the
runtime values of some kernel variables using gdb.
I am issuing the gdb command as follows:
gdb vmlinux /proc/kcore
This displays the message
/proc/kcore: Operation not permitted
before the (gdb) prompt is displayed.
gdb then prints a value of 0 for any valid variable that is requested.
vmlinux appears to be OK, as gdb correctly identifies undefined variables.
The problem seems to be with /proc/kcore. This file has a permission
of 400. I
am using the Red Hat distribution.
Any help is appreciated. Thanks,
Uma.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |