| 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
|