bc1b77cdc8a9cb1959a80edbd0b0e636801a27e5 |
|
17-May-2015 |
philippe <philippe@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Avoid warning about %d and long int git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15252 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_gdbserver/remote-utils.c
|
8568c99d33c6e0ad6738ebb39da9467a71b847dd |
|
17-May-2015 |
philippe <philippe@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Improve trace of pkt send by V gdbsrv: * show the len * print binary date using \octal notation (like printf, when given non printable chars) git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15250 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_gdbserver/remote-utils.c
|
75d8a4e4e4c3c471f366683faa903aef0ce91405 |
|
26-Mar-2015 |
philippe <philippe@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Have the very detailed gdbsrv debuglog (e.g. exchange of packets between GDB and V gdbsrv, fetching/setting registers, ...) done at debuglog level 3 instead of 1. This allows to do gdbsrv commands at debuglog level 2 without seeing too much trace. git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15039 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_gdbserver/remote-utils.c
|
7463e49387b46e66b6612ff4b9683c612c92f804 |
|
26-Feb-2015 |
florian <florian@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Include pub_core_aspacemgr.h only where needed. Also fixes BZ #344235. git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14966 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_gdbserver/remote-utils.c
|
b12f502f96dee3ead809420943ce5386ded4775a |
|
09-Feb-2015 |
philippe <philippe@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Ensure vgdb gets the nr of threads from Valgrind via shared memory, rather than using a compile time constant. This is in preparation for a future change by Florian, to have the max nr of threads specifiable at startup via a clo git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14924 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_gdbserver/remote-utils.c
|
5b99e6669a0b2a925bb3fb2604259cc317963b6d |
|
29-Nov-2014 |
florian <florian@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Fix BZ 334802. Patch by Mark Wielaard with a few mods to make it apply. r14794 is related as well. Also: remove -Wno-format-zero-length from compile options. git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14795 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_gdbserver/remote-utils.c
|
f2df33244d9295a6e0305cd5edddd97d18f88e2c |
|
15-Sep-2014 |
philippe <philippe@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Fix leak that can happen in case of IO error between V gdbsrv and vgdb. Spotted by Florian Krohm/IBM BEAM checker git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14541 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_gdbserver/remote-utils.c
|
511df4ecbd147628cb33f556e34d4c0dbfbff51a |
|
12-Sep-2014 |
florian <florian@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
When piecing together the file name of a vgdb FIFO do not allow user names and host names containing '/' characters. git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14526 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_gdbserver/remote-utils.c
|
9450a8eaa52f6c46a472f63ea7e81ad2a11615a6 |
|
06-Sep-2014 |
philippe <philippe@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Fix 338698 race condition between gdbsrv and vgdb on startup git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14475 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_gdbserver/remote-utils.c
|
38a74d2cc4670e3eb559adff51a376cd6ec98005 |
|
30-Aug-2014 |
philippe <philippe@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
The semantic of the stack bounds is not consistent or is not described. At various places, there were either some assumption that the 'end' boundary (highest address) was either not included, included, or was the highest addressable word, or the highest addressable byte. This e.g. was very visible when doing: ./vg-in-place -d -d ./helgrind/tests/tc01_simple_race|&grep regi giving --24040:2:stacks register 0xBEDB4000-0xBEDB4FFF as stack 0 --24040:2:stacks register 0x402C000-0x4A2C000 as stack 1 showing that the main stack end was (on x86) not the highest word but the highest byte, while for the thread 1, the registered end was a byte not part of the stack. The attached patch ensures that stack bounds semantic are documented and consistent. Also, some of the stack handling code is factorised. The convention that the patch ensures and documents is: start is the lowest addressable byte, end is the highest addressable byte. (the words 'min' and 'max' have been kept when already used, as this wording is consistent with the new semantic of start/end). In various debug log, used brackets [ and ] to make clear that both bounds are included. The code to guess and register the client stack was duplicated in all the platform specific syswrap-<plat>-<os>.c files. Code has been factorised in syswrap-generic.c The patch has been regression tested on x86, amd64, ppc32/64, s390x. It has been compiled and one test run on arm64. Not compiled/not tested on darwin, android, mips32/64, arm More in details, the patch does the following: coregrind/pub_core_aspacemgr.h include/valgrind.h include/pub_tool_machine.h coregrind/pub_core_scheduler.h coregrind/pub_core_stacks.h - document start/end semantic in various functions also in pub_tool_machine.h: - replaces unclear 'bottommost address' by 'lowest address' (unclear as stack bottom is or at least can be interpreted as the 'functional' bottom of the stack, which is the highest address for 'stack growing downwards'). coregrind/pub_core_initimg.h replace unclear clstack_top by clstack_end coregrind/m_main.c updated to clstack_end coregrind/pub_core_threadstate.h renamed client_stack_highest_word to client_stack_highest_byte coregrind/m_scheduler/scheduler.c computes client_stack_highest_byte as the highest addressable byte Update comments in call to VG_(show_sched_status) coregrind/m_machine.c coregrind/m_stacktrace.c updated to client_stack_highest_byte, and switched stack_lowest/highest_word to stack_lowest/highest_byte accordingly coregrind/m_stacks.c clarify semantic of start/end, added a comment to indicate why we invert start/end in register call (note that the code find_stack_by_addr was already assuming that end was included as the checks were doing e.g. sp >= i->start && sp <= i->end coregrind/pub_core_clientstate.h coregrind/m_clientstate.c renames Addr VG_(clstk_base) to Addr VG_(clstk_start_base) (start to indicate it is the lowest address, base suffix kept to indicate it is the initial lowest address). coregrind/m_initimg/initimg-darwin.c updated to VG_(clstk_start_base) replace unclear iicii.clstack_top by iicii.clstack_end updated clstack_max_size computation according to both bounds included. coregrind/m_initimg/initimg-linux.c updated to VG_(clstk_start_base) updated VG_(clstk_end) computation according to both bounds included. replace unclear iicii.clstack_top by iicii.clstack_end coregrind/pub_core_aspacemgr.h extern Addr VG_(am_startup) : clarify semantic of the returned value coregrind/m_aspacemgr/aspacemgr-linux.c removed a copy of a comment that was already in pub_core_aspacemgr.h (avoid double maintenance) renamed unclear suggested_clstack_top to suggested_clstack_end (note that here, it looks like suggested_clstack_top was already the last addressable byte) * factorisation of the stack guessing and registration causes mechanical changes in the following files: coregrind/m_syswrap/syswrap-ppc64-linux.c coregrind/m_syswrap/syswrap-x86-darwin.c coregrind/m_syswrap/syswrap-amd64-linux.c coregrind/m_syswrap/syswrap-arm-linux.c coregrind/m_syswrap/syswrap-generic.c coregrind/m_syswrap/syswrap-mips64-linux.c coregrind/m_syswrap/syswrap-ppc32-linux.c coregrind/m_syswrap/syswrap-amd64-darwin.c coregrind/m_syswrap/syswrap-mips32-linux.c coregrind/m_syswrap/priv_syswrap-generic.h coregrind/m_syswrap/syswrap-x86-linux.c coregrind/m_syswrap/syswrap-s390x-linux.c coregrind/m_syswrap/syswrap-darwin.c coregrind/m_syswrap/syswrap-arm64-linux.c Some files to look at more in details: syswrap-darwin.c : the handling of sysctl(kern.usrstack) looked buggy to me, and has probably be made correct by the fact that VG_(clstk_end) is now the last addressable byte. However,unsure about this, as I could not find any documentation about sysctl(kern.usrstack). I only find several occurences on the web, showing that the result of this is page aligned, which I guess means it must be 1+ the last addressable byte. syswrap-x86-darwin.c and syswrap-amd64-darwin.c I suspect the code that was computing client_stack_highest_word was wrong, and the patch makes it correct. syswrap-mips64-linux.c not sure what to do for this code. This is the only code that was guessing the stack differently from others. Kept (almost) untouched. To be discussed with mips maintainers. coregrind/pub_core_libcassert.h coregrind/m_libcassert.c * void VG_(show_sched_status): renamed Bool valgrind_stack_usage to Bool stack_usage if stack_usage, shows both the valgrind stack usage and the client stack boundaries coregrind/m_scheduler/scheduler.c coregrind/m_gdbserver/server.c coregrind/m_gdbserver/remote-utils.c Updated comments in callers to VG_(show_sched_status) git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14392 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_gdbserver/remote-utils.c
|
a0a0c6bc3ed5df4cf05db6ce90c881199152127d |
|
31-Jul-2014 |
philippe <philippe@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
take endianness into account in arm64 fpsr xfer, use VKI_LITTLE_ENDIAN to decide to reverse or not bytes in image function git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14223 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_gdbserver/remote-utils.c
|
def5aae79084c7b1128674105f9e657e2af0d5dc |
|
09-Jul-2014 |
philippe <philippe@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Rollback the (functional) effect of 13944 and 14134 Re-opening the FIFO before closing it gives (difficult to understand) problems => rollback the change that keeps the FIFO opened. Rather handle the race condition by retrying at vgdb side. See extensive comments in remote-utils.c git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14147 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_gdbserver/remote-utils.c
|
e1206672ceb16745cef1d1ed099372b3158882c9 |
|
05-Jul-2014 |
philippe <philippe@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Follow up to rev 13944 13944 objective was to avoid having a vgdb that connects to a just forked child that would have the FIFO still opened, while its parent would close it. However, in case a previous vgdb closed the FIFO, the read FIFO in the parent is put in 'eof status' by the kernel. So, readchar will then return eof in the parent unless another vgdb re-opens the FIFO in write. So, gdbsrv does not stop anymore on error if needed, due to this readchar giving eof. The only way to reset this eof condition is to close the fd. But we must always have the FIFO open (to avoid the race condition that rev 13944 fixed) => in case of error, first re-open the FIFO, before closing the (previous) FIFO fd (which is in eof state and cannot be properly used anymore). git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14134 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_gdbserver/remote-utils.c
|
02fbf7f71a2dbe9258b2d5dc530eaaa59b8890c9 |
|
17-May-2014 |
philippe <philippe@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
On old kernel, poll syscall being ptraced (vgdb+ptrace) is not necessarily properly restarted. Instead, it can fail with EINTR, even if no signal was effectively received. Handle such case by retrying the poll syscall when the poll syscall is failing due to EINTR git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13977 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_gdbserver/remote-utils.c
|
5c683cf8f5095d1a0dcf6b8791bcaf4aee09c722 |
|
14-May-2014 |
mjw <mjw@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Support -Wformat -Werror=format-security. Check if gcc supports -Wformat -Werror=format-security and use it if so. Fix m_gdbserver/remote-utils.c sr_perror call. Fixes Bug #334727. git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13962 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_gdbserver/remote-utils.c
|
853a1ce66afb2e5517bbac1dededea19a27b1534 |
|
12-May-2014 |
philippe <philippe@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
In case gdbsrv poll syscall fails, produces more information gdbsrv poll syscall seems to very infrequently (1 on 100000 vgdb invocationsĀ§) to be EINTR-upted. So, when poll syscall fails, output stacktrace + sigmask status to capture more info about the problem. This is a follow-up/extension of r13748, which showed poll was interrupted but it is not clear why. In particular, all async signals are supposed to be masked at the time vgdb has forced an invocation git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13953 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_gdbserver/remote-utils.c
|
ed4c5c1e52c80509e809d438db19b77a287ef79a |
|
08-May-2014 |
philippe <philippe@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Keep the reading side of the FIFO opened after a vgdb disconnect Otherwise, if the valgrind process has just forked before the vgdb connect, and the child has not yet closed the FIFO it inheritates from its parent, and a 2nd vgdb is started before the parent has re-opened the reading side FIFO, the 2nd vgdb can connect to the child, which will not handle the wakeup character/connection request, and vgdb will have a write error and/or block. git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13944 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_gdbserver/remote-utils.c
|
08a0e88312de3bf39ef35e1f47e79e2537041941 |
|
29-Apr-2014 |
philippe <philippe@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Also give the indication on how to use vgdb when --vgdb-stop-at is given git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13919 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_gdbserver/remote-utils.c
|
180a7500bf2464d5b16cddb5618b91fb3f095998 |
|
20-Apr-2014 |
philippe <philippe@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
- The option "--vgdb-stop-at=event1,event2,..." allows the user to ask GDB server to stop before program execution, at the end of the program execution and on Valgrind internal errors. - A new monitor command "v.set hostvisibility" that allows GDB server to provide access to Valgrind internal host status/memory. git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13900 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_gdbserver/remote-utils.c
|
cffe2a55d903655761ccc6025a23b823bee10170 |
|
11-Jan-2014 |
philippe <philippe@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
add --vgdb-prefix arg to callgrind_control If valgrind is started with --vgdb-prefix arg, then callgrind_control cannot find and control this valgrind. So, add an (optional) argument to callgrind_control, and have callgrind tool report the needed vgdb prefix argument if the user supplied this arg. git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13769 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_gdbserver/remote-utils.c
|
4254584008012b975d47540812612f297ed68d0a |
|
05-Dec-2013 |
philippe <philippe@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Minor tweak in the VG_(poll) syscall and callers: have a way to show the error in case the poll syscall unexpectedly fails. git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13748 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_gdbserver/remote-utils.c
|
4be47bca8e94c0ae640d83287b6656e4cbfb35f0 |
|
05-Dec-2013 |
philippe <philippe@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Minor tweak in the vgdb instructions output by valgrind: to make copy/paste and then editing the command easier, put the --pid=3393 at the end of the instruction output by valgrind. So, in gdb command history, one can just recuperate the previous target command in the history and more easily change the pid. I.e. have: target remote | /home/philippe/valgrind/refactor_vgdb/Inst/lib/valgrind/../../bin/vgdb --vgdb-prefix=truc --pid=3393 instead of target remote | /home/philippe/valgrind/refactor_vgdb/Inst/lib/valgrind/../../bin/vgdb --pid=3393 --vgdb-prefix=truc git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13747 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_gdbserver/remote-utils.c
|
01a492ec43ea5da29b9db4b044014e96f52b441b |
|
30-Jul-2013 |
philippe <philippe@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
add a test + assert for GDB bug bypassed in r13472 * modify mcwatchpoints to print a 50000 char array * add an assert to check the max allowed size git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13476 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_gdbserver/remote-utils.c
|
03ffc6ebe6ae367d1ace1398d9584cbd45a3d90c |
|
26-Jul-2013 |
philippe <philippe@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Bypass GDB bug which asks to read packet slightly too big GDB sometimes asks slightly too big read packets (no taking into account the packet overhead). Bypass the problem by allocating slightly more than needed if GDB would only ask the correct maximum size. git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13472 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_gdbserver/remote-utils.c
|
25583179757e4393a687330732675e3c63c0e0d1 |
|
09-May-2013 |
philippe <philippe@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
fix 319235 --db-attach=yes is broken with Yama ptrace scoping enabled On Ubuntu systems, ptrace_scoping could forbid a process to ptrace another. This ptrace scoping was already handled for vgdb by using SET_PTRACER (the valgrind process must be ptraced by vgdb when it is blocked in a syscall). set_ptracer is however also needed when the old mechanism --db-attach=yes is used. The following changes are done: * make the set_ptracer logic callable outside gdbserver * make set_ptracer less restrictive (i.e. allow all processes of the user to ptrace). This removes a limitation for vgdb. * call the set_ptracer in the child launched for --db-attach=yes * cleaned up the ptrace scope restriction message and doc as vgdb is now working properly by default, even with ptrace_scope enabled. git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13384 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_gdbserver/remote-utils.c
|
46207652a0c99a2c8b0f05eafce3ca3ec533c121 |
|
20-Jan-2013 |
philippe <philippe@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Implement --merge-recursive-frames + provide VALGRIND_MONITOR_COMMAND client req. In a big applications, some recursive algorithms have created hundreds of thousands of stacktraces, taking a lot of memory. Option --merge-recursive-frames=<number> tells Valgrind to detect and merge (collapse) recursive calls when recording stack traces. The value is changeable using the monitor command 'v.set merge-recursive-frames'. Also, this provides a new client request: VALGRIND_MONITOR_COMMAND allowing to execute a gdbsrv monitor command from the client program. git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13246 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_gdbserver/remote-utils.c
|
3e7986312a0ffc7646b0552d4c4ea3744a870e73 |
|
24-Nov-2012 |
florian <florian@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Fix some casts that removed const-ness as pointed out by GCC's -Wcast-qual. git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13138 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_gdbserver/remote-utils.c
|
6bd9dc18c043927c1196caba20a327238a179c42 |
|
23-Nov-2012 |
florian <florian@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Changes to allow compilation with -Wwrite-strings. That compiler option is not used for testcases, just for valgrind proper. git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13137 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_gdbserver/remote-utils.c
|
19f91bbaedb4caef8a60ce94b0f507193cc0bc10 |
|
10-Nov-2012 |
florian <florian@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Fix more Char/HChar mixups. Closing in... git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13119 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_gdbserver/remote-utils.c
|
349a39142e16d060936911c1792cc0a5d2fe63fe |
|
23-May-2012 |
philippe <philippe@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Prepare for AVX support : restructure gdbsrv/target/valgrind-low/arch low AVX support implies to have target xml files which are selected according to the machine hwcaps. This change improves the structure of the gdbserver software layering to prepare for this. Basically, the protocol files (e.g. server.c) are now calling directly the valgrind target operations which are now defined in target.h/target.c (before, there was a level of indirection inheritated from the GDB structure which was useless for valgrind gdbserver). + clarified some comments git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12579 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_gdbserver/remote-utils.c
|
c42a5ccb75501c196e3bcd1a6ef56298a635ece8 |
|
15-Apr-2012 |
philippe <philippe@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Change permission mask for FIFOs and shared memory to 0600 instead of 0666 Following a discussion about which user can debug which VAlgrind gdbserver: The default umask will remove the "other" and "group" write bits. Without the w bits, nothing works in any case. Moreover, if the vgdb process does not belong to the user running the V gdbserver, connections are also not possible. => remove useless/confusing bits. git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12505 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_gdbserver/remote-utils.c
|
578642013e14f1d5d3f36cfebf4ad51124ba5e77 |
|
22-Feb-2012 |
philippe <philippe@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Avoid having holes in the VgdbShared struct. These holes are not initialized, and writing these uninitialised bytes to the mapped file causes an error being reported when running Valgrind inside Valgrind. Having no holes avoid having this error. git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12397 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_gdbserver/remote-utils.c
|
ae52a9398788dfa1b4d51b03013e8665268ad6df |
|
13-Jan-2012 |
philippe <philippe@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Valgrind gdbserver can open/close connections multiple times => avoid leak when re-computing the default vgdb prefix. Similar change in vgdb.c git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12328 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_gdbserver/remote-utils.c
|
de80335ebfdb0ae7f9ccc37aa4682182f3a09eec |
|
01-Dec-2011 |
philippe <philippe@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Give a better help message for gdbserver when VALGRIND_LIB is set. This ensures a correct help msg is given when the valgrind installation is moved, and VALGRIND_LIB is then set to the new valgrind lib location. Note it does not improve the help msg when valgrind is run "in place" (e.g. when using vg-in-place). (Patch from Paul Pluzhnikov). git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12278 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_gdbserver/remote-utils.c
|
ab8630fd1c559a3d8a3e429cf8e9f2e4b94a3ff6 |
|
29-Sep-2011 |
florian <florian@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Change the name of the pipes for vgdb by adding username and hostname. Those are obtained by looking at some commonly defined environment variables. That should help with problems where /tmp is shared or process IDs get recycled. We had some intermittent nightly build issues because of that. Partial fix for bugzilla #280757. git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12071 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_gdbserver/remote-utils.c
|
b985e2de52983cafd2d17cc6c9e60064847777fd |
|
29-Sep-2011 |
florian <florian@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Remove hardwired /tmp directory in vgdb. Honour VG_TMPDIR and TMPDIR which was introduced when fixing bugzilla #267020. Factor out VG_(tmpdir). New function VG_(vgdb_path_prefix). Partially fixes bugzilla #280757. git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12063 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_gdbserver/remote-utils.c
|
4b03d390a5e185efda5ca79eddf4016a85624048 |
|
13-Aug-2011 |
bart <bart@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
vgdb: Unlink pipes and mapped file before (re)creating these. git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11972 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_gdbserver/remote-utils.c
|
45fa417910da140c522eedd18153a2b1d8a9b35e |
|
26-Jun-2011 |
sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
GDB server: * fix error in usability msg * make a test more deterministic (Philippe Waroquiers, philippe.waroquiers@skynet.be). Bug 214909 comment 107. git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11835 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_gdbserver/remote-utils.c
|
1568e17cf07007c677274ce877973c7ed9357df2 |
|
18-Jun-2011 |
sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Minor GDBserver source tidying. Also a small usability fix: if --vgdb-error=N is specified, print a bit of text telling the user the magic commands to give GDB in order to attach to the process. git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11822 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_gdbserver/remote-utils.c
|
1ac21102f27aee0114733566ef4abd559051c5da |
|
15-Jun-2011 |
sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Fix safe_fd exhaustion in fork chain caused by non closing of shared_mem_fd Patch that fixes the problem reported by Christian Borntraeger. The problem was created by keeping the shared memory mapped file opened without reason till the process does an exec. In case of a chain of forked processes (without exec), the range of safe_fd reserved for Valgrind own usage becomes exhausted. * coregrind/m_gdbserver/remote-utils.c : do not VG_(safe_fd) shared_mem_fd (as it is now closed directly) close shared_mem_fd once file is mmap-ed and written. * gdbserver_tests/nlfork_chain.stderr.exp,nlfork_chain.vgtest, fork_chain.c,nlfork_chain.stdout.exp: new files * gdbserver_tests/Makefile.am: modified for new nlfork_chain test (patch from #214909 c 103, Philippe Waroquiers, philippe.waroquiers@skynet.be) git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11818 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_gdbserver/remote-utils.c
|
d142f99836471d4245250247cc9ac7bc5a1391fa |
|
17-May-2011 |
sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
gdbserver: misc fixes (#214909 c 77) Fix some tests on ppc-debian6,s390x + handled Nick Nethercote, Josef Weidendorfer comments * improved testing & related doc - added option --vex-iropt-precise-memory-exns=yes to mcsig(no)pass.vgtest + updated manual-core.xml - cleanup some comments in *.vgtest - modified filter_gdb and filter_memcheck_monitor to handle specific ppc/debian6.0 mcsig(no)pass output handle specific s390x 'missing debug info' - added more information in README_DEVELOPPERS on how to investigate failing gdbserver tests. * handled Nick Nethercote comment: Replaced kludgy ms.snapshot detailed by ms.detailed_snaphot Updated documentation and test. * handled Josef Weindendorfer comments: - do not report an error if ptrace_scope file can't be read. Instead, a debug trace is done if -d (debug) option given - added an option -l to give the list of active Valgrind gdbserver. Useful a.o. to support callgrind_control. Updated documentation - added ref. to vgdb help in the vgdb --help message (Philippe Waroquiers, philippe.waroquiers@skynet.be) git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11770 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_gdbserver/remote-utils.c
|
3b290486cd4cd601b20e04340e593c9ed9717e5f |
|
06-May-2011 |
sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Implement a GDB server in Valgrind. See #214909. (Philippe Waroquiers, philippe.waroquiers@skynet.be) git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11727 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_gdbserver/remote-utils.c
|