From: Philippe Waroquiers Date: Tue, 27 Dec 2011 09:03:36 +0000 (+0000) Subject: Small doc changes: X-Git-Tag: svn/VALGRIND_3_8_0~533 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=2d4970f4940d596ced6eece58f87f7755e07a9ca;p=thirdparty%2Fvalgrind.git Small doc changes: * In core advanced manual, replace 3.7.0 by current release. * cleanup in m_gdbserver/README_DEVELOPPERS git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12320 --- diff --git a/coregrind/m_gdbserver/README_DEVELOPERS b/coregrind/m_gdbserver/README_DEVELOPERS index 153660f325..e7e9fe4bfc 100644 --- a/coregrind/m_gdbserver/README_DEVELOPERS +++ b/coregrind/m_gdbserver/README_DEVELOPERS @@ -193,7 +193,7 @@ At least on a fedora core 12 (kernel 2.6.32), syscall restart of read and select are working ok and red-hat 5.3 (an old kernel), everything works properly. -Need to investigate if darwin and/or AIX can similarly do syscall +Need to investigate if darwin can similarly do syscall restart with ptrace. The vgdb argument --max-invoke-ms=xxx allows to control the nr of @@ -219,7 +219,7 @@ valgrind-low-* are inspired from gdb files. This code had to be changed to integrate properly within valgrind (e.g. no libc usage). Some of these changes have been ensured by using the preprocessor to replace calls by valgrind equivalent, -e.g. #define memcpy(...) VG_(memcpy) (...). +e.g. #define strcmp(...) VG_(strcmp) (...). Some "control flow" changes are due to the fact that gdbserver inside valgrind must return the control to valgrind when the 'debugged' @@ -298,13 +298,6 @@ Modify coregrind/Makefile.am: If you have target xml description, also add them in pkglib_DATA -A not handled comment given by Julian at FOSDEM. ------------------------------------------------- -* the check for vgdb-poll in scheduler.c could/should be moved to another place: - instead of having it in run_thread_for_a_while - the vgdb poll check could be in VG_(scheduler). - (not clear to me why one is better than the other ???) - TODO and/or additional nice things to have ------------------------------------------ * many options can be changed on-line without problems. @@ -330,24 +323,6 @@ TODO and/or additional nice things to have of these architectures might complete this (see the GDBTD in valgrind-low-*.c) -* "hardware" watchpoint (read/write/access watchpoints) are implemented - but can't persuade gdb to insert a hw watchpoint of what valgrind - supports (i.e. of whatever length). - The reason why gdb does not accept a hardware watch of let's say - 10 bytes is: -default_region_ok_for_hw_watchpoint (addr=134520360, len=10) at target.c:2738 -2738 return (len <= gdbarch_ptr_bit (target_gdbarch) / TARGET_CHAR_BIT); -#0 default_region_ok_for_hw_watchpoint (addr=134520360, len=10) - at target.c:2738 -2738 return (len <= gdbarch_ptr_bit (target_gdbarch) / TARGET_CHAR_BIT); -#1 0x08132e65 in can_use_hardware_watchpoint (v=0x85a8ef0) - at breakpoint.c:8300 -8300 if (!target_region_ok_for_hw_watchpoint (vaddr, len)) -#2 0x0813bd17 in watch_command_1 (arg=0x84169f0 "", accessflag=2, - from_tty=) at breakpoint.c:8140 - A small patch in gdb remote.c allowed to control the remote target watchpoint - length limit. This patch is to be submitted. - * Currently, at least on recent linux kernel, vgdb can properly wake up a valgrind process which is blocked in system calls. Maybe we need to see till which kernel version the ptrace + syscall restart diff --git a/docs/xml/manual-core-adv.xml b/docs/xml/manual-core-adv.xml index ad65e37f07..3b602f9a01 100644 --- a/docs/xml/manual-core-adv.xml +++ b/docs/xml/manual-core-adv.xml @@ -520,7 +520,7 @@ to the port number used by vgdb: adb can forward tcp/ip between different port numbers. -In the 3.7.0 release, the GDB server is not enabled by default +In the current release, the GDB server is not enabled by default for Android, due to problems in establishing a suitable directory in which Valgrind can create the necessary FIFOs (named pipes) for communication purposes. You can stil try to use the GDB server, but