You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(122) |
Nov
(152) |
Dec
(69) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(6) |
Feb
(25) |
Mar
(73) |
Apr
(82) |
May
(24) |
Jun
(25) |
Jul
(10) |
Aug
(11) |
Sep
(10) |
Oct
(54) |
Nov
(203) |
Dec
(182) |
| 2004 |
Jan
(307) |
Feb
(305) |
Mar
(430) |
Apr
(312) |
May
(187) |
Jun
(342) |
Jul
(487) |
Aug
(637) |
Sep
(336) |
Oct
(373) |
Nov
(441) |
Dec
(210) |
| 2005 |
Jan
(385) |
Feb
(480) |
Mar
(636) |
Apr
(544) |
May
(679) |
Jun
(625) |
Jul
(810) |
Aug
(838) |
Sep
(634) |
Oct
(521) |
Nov
(965) |
Dec
(543) |
| 2006 |
Jan
(494) |
Feb
(431) |
Mar
(546) |
Apr
(411) |
May
(406) |
Jun
(322) |
Jul
(256) |
Aug
(401) |
Sep
(345) |
Oct
(542) |
Nov
(308) |
Dec
(481) |
| 2007 |
Jan
(427) |
Feb
(326) |
Mar
(367) |
Apr
(255) |
May
(244) |
Jun
(204) |
Jul
(223) |
Aug
(231) |
Sep
(354) |
Oct
(374) |
Nov
(497) |
Dec
(362) |
| 2008 |
Jan
(322) |
Feb
(482) |
Mar
(658) |
Apr
(422) |
May
(476) |
Jun
(396) |
Jul
(455) |
Aug
(267) |
Sep
(280) |
Oct
(253) |
Nov
(232) |
Dec
(304) |
| 2009 |
Jan
(486) |
Feb
(470) |
Mar
(458) |
Apr
(423) |
May
(696) |
Jun
(461) |
Jul
(551) |
Aug
(575) |
Sep
(134) |
Oct
(110) |
Nov
(157) |
Dec
(102) |
| 2010 |
Jan
(226) |
Feb
(86) |
Mar
(147) |
Apr
(117) |
May
(107) |
Jun
(203) |
Jul
(193) |
Aug
(238) |
Sep
(300) |
Oct
(246) |
Nov
(23) |
Dec
(75) |
| 2011 |
Jan
(133) |
Feb
(195) |
Mar
(315) |
Apr
(200) |
May
(267) |
Jun
(293) |
Jul
(353) |
Aug
(237) |
Sep
(278) |
Oct
(611) |
Nov
(274) |
Dec
(260) |
| 2012 |
Jan
(303) |
Feb
(391) |
Mar
(417) |
Apr
(441) |
May
(488) |
Jun
(655) |
Jul
(590) |
Aug
(610) |
Sep
(526) |
Oct
(478) |
Nov
(359) |
Dec
(372) |
| 2013 |
Jan
(467) |
Feb
(226) |
Mar
(391) |
Apr
(281) |
May
(299) |
Jun
(252) |
Jul
(311) |
Aug
(352) |
Sep
(481) |
Oct
(571) |
Nov
(222) |
Dec
(231) |
| 2014 |
Jan
(185) |
Feb
(329) |
Mar
(245) |
Apr
(238) |
May
(281) |
Jun
(399) |
Jul
(382) |
Aug
(500) |
Sep
(579) |
Oct
(435) |
Nov
(487) |
Dec
(256) |
| 2015 |
Jan
(338) |
Feb
(357) |
Mar
(330) |
Apr
(294) |
May
(191) |
Jun
(108) |
Jul
(142) |
Aug
(261) |
Sep
(190) |
Oct
(54) |
Nov
(83) |
Dec
(22) |
| 2016 |
Jan
(49) |
Feb
(89) |
Mar
(33) |
Apr
(50) |
May
(27) |
Jun
(34) |
Jul
(53) |
Aug
(53) |
Sep
(98) |
Oct
(206) |
Nov
(93) |
Dec
(53) |
| 2017 |
Jan
(65) |
Feb
(82) |
Mar
(102) |
Apr
(86) |
May
(187) |
Jun
(67) |
Jul
(23) |
Aug
(93) |
Sep
(65) |
Oct
(45) |
Nov
(35) |
Dec
(17) |
| 2018 |
Jan
(26) |
Feb
(35) |
Mar
(38) |
Apr
(32) |
May
(8) |
Jun
(43) |
Jul
(27) |
Aug
(30) |
Sep
(43) |
Oct
(42) |
Nov
(38) |
Dec
(67) |
| 2019 |
Jan
(32) |
Feb
(37) |
Mar
(53) |
Apr
(64) |
May
(49) |
Jun
(18) |
Jul
(14) |
Aug
(53) |
Sep
(25) |
Oct
(30) |
Nov
(49) |
Dec
(31) |
| 2020 |
Jan
(87) |
Feb
(45) |
Mar
(37) |
Apr
(51) |
May
(99) |
Jun
(36) |
Jul
(11) |
Aug
(14) |
Sep
(20) |
Oct
(24) |
Nov
(40) |
Dec
(23) |
| 2021 |
Jan
(14) |
Feb
(53) |
Mar
(85) |
Apr
(15) |
May
(19) |
Jun
(3) |
Jul
(14) |
Aug
(1) |
Sep
(57) |
Oct
(73) |
Nov
(56) |
Dec
(22) |
| 2022 |
Jan
(3) |
Feb
(22) |
Mar
(6) |
Apr
(55) |
May
(46) |
Jun
(39) |
Jul
(15) |
Aug
(9) |
Sep
(11) |
Oct
(34) |
Nov
(20) |
Dec
(36) |
| 2023 |
Jan
(79) |
Feb
(41) |
Mar
(99) |
Apr
(169) |
May
(48) |
Jun
(16) |
Jul
(16) |
Aug
(57) |
Sep
(19) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
|
1
|
2
(1) |
|
3
|
4
(4) |
5
(4) |
6
|
7
|
8
|
9
|
|
10
(2) |
11
(2) |
12
(2) |
13
|
14
|
15
(2) |
16
(1) |
|
17
(2) |
18
(2) |
19
(3) |
20
(4) |
21
(1) |
22
|
23
|
|
24
(7) |
25
|
26
(4) |
27
(7) |
28
(2) |
29
(1) |
30
(2) |
|
31
|
|
|
|
|
|
|
|
From: Philippe W. <phi...@sk...> - 2016-07-26 21:56:12
|
On Tue, 2016-07-26 at 16:59 -0400, Christian Convey wrote: > Hi Philippe, > > Thanks very much for your response! You provided lots of helpful > information. A few replies below. Which are clarifying the objective :). Some more feedback below ... > > > Here's the bigger picture regarding what I'm trying to do... > > > As part of a personal project, I'm trying to implement a Valgrind tool > which monitors operations on a user-specified region of memory. > Basically, a watchpoint on steroids. > > I want my analysis of a memory region to be active when, and only > when, the function in which one of my memory-watches is defined is > present on the callstack. Valgrind memcheck + gdb provides a reasonably fast (reasonably fast = much faster than the gdb software watchpoints) watchpoints. There is also no limitations in size or numbers of these 'extended watchpoints'. See http://www.valgrind.org/docs/manual/manual-core-adv.html#manual-core-adv.gdbserver-limitations Hardware watchpoint support by the Valgrind gdbserver. GDB was modified so as to properly work with the (unlimited) 'simulated hardware watchpoints' as provided by Valgrind gdbserver. The gdb manual tells: " GDB automatically deletes watchpoints that watch local (automatic) variables, or expressions that involve such variables, when they go out of scope, ...." So, I think you should be able to implement what you need relatively simply with : * put a breakpoint on function B * add a command list to this breakpoint, doing: watch x continue and that should work (?). In other words, when entering B, gdb will encounter the breakpoint, and will translate and create a hw watchpoint (that valgrind gdbserver will implement reasonably efficiently). And as I understand, gdb is supposed to detect that B returns, and delete the watchpoint. That might however not be ultra-fast, if you have such watchpoints in often called functions, as this implies some not trivial work by GDB (breakpoint, create watchpoint, detect return of function and delete the watchpoint). > Consider this example: > > ///////////// BEGIN EXAMPLE ///////////// > > > 1: // C is a mystery function. > 2: // It might even recursively call B(). > 3: extern void C( int* ); > 4: > 5: void B() { > 6: int X = 42; > 7: int Y = 100; > 8: C( &X ); > 9: } > > 10: > 11: void A() { > 12: for (int i = 0; i < 1000; ++i) { > 13: B(); > 14: } > 15: } > > I'd like to be able to define a quasi-watchpoint such as "the variable > X in function B". > > > For each activation of function "B", I want my Valgrind tool to be > notified with the numeric address range occupied by that frame's > instance of "B". > > > I also want my Valgrind tool to be notified each time function "B" > returns, so it can deactivate the memory-watching that was established > when that stack frame was created. > > > The loop in function A() to point out that it's not always practical > for a human to perform the conversion from the symbolic > naming of the memory to be evaluated ("X in function B()") to a > specific numeric address. > > > ///////////// END EXAMPLE ///////////// > > > I do not think I can perform the kinds of analyses I want entirely > within GDB, even using its Python API. GDB hardware watchpoints can't > handle the sizes of memory regions I want to analyze, and gdb software > breakpoints are too slow for my needs. As discussed above, valgrind memcheck+gdbserver is providing (reasonably fast) simulated hardware watchpoint, and no limit on nr or size of such watchpoints. > > > I also believe that none of the currently available Valgrind tools > performs the kind of memory-operation analyses I want to do. I think > Valgrind is the right framework for what I want to do, but AFAICT I'll > want to write a new tool. > > > So my challenge is to somehow get GDB's help in converting an lvalue > expression like the one mentioned above, into a form that a Valgrind > tool can make sense of. > > At the moment I'm looking to do this with a combination of: > > > * Running GDB commands at GDB breakpoints, and > > > * Having those commands send the relevant information, including > numeric (not symbolic) address ranges to my tool via `gdb > monitor`). > > > I think this approach is workable, but I'd like to avoid adding > code/scripts to BOTH Valgrind and GDB. > > > >> * "VG_(get_data_description)" seems to be on the right track, > >> because it searches (nearby) stack frames as well as global > variables. > > Yes, this is basically what it does (address to 'symbol'). > >> But it seems designed for address-to-symbol translation (I need the > >> opposite), and it doesn't sound smart about C's rules regarding > >> identifier scoping, etc. > > Not too sure what you mean about identifier scoping. It searches > > global and stack variables, taking the C rules into account > > (as these are implied by the stack structure that it scans). > > > AFAIK, resolving a C identifier should never need to involve looking > at the variables/parameters of any stack frame other than the current > one. Since the docs for "VG_(get_data_description)" mentioned looking > at additional stack frames, I assumed that routine implements > something other than the C-language's resolution rules. VG_(get_data_description) is translating an address to a symbol, and such things are taking into account 'C scope' as implemented by the stack. Even for doing symbol to address, you must indicate in which frame you want to do the resolution, otherwise the symbol (var name) is ambiguous. Of course, this 'explicit frame' might be limited to the 'current frame'. > > > > > > IMO this is hard :). > Thanks very much for the warning! I will henceforth be less cavalier > about that option :) At this point, probably worth first experimenting with GDB + valgrind gdbserver + memcheck, and the watchpoint support by Valgrind gdbserver. Philippe > |
|
From: Christian C. <chr...@gm...> - 2016-07-26 20:59:12
|
Hi Philippe,
Thanks very much for your response! You provided lots of helpful
information. A few replies below.
On Tue, Jul 26, 2016 at 4:15 PM, Philippe Waroquiers <
phi...@sk...> wrote:
> I am not sure to understand why you need a Valgrind tool to do that.
> If you are busy debugging an executable,
> then gdb can give you the address and content of global variables,
> function arguments and local variables.
> So, e.g. for the above, you could in gdb do:
> p &x
> or
> info address x
> (this last one will rather explain how the address is computed e.g. by
> giving the DWARF expression).
> The size can be found using p sizeof(x)
> And of course, the content using p x
Here's the bigger picture regarding what I'm trying to do...
As part of a personal project, I'm trying to implement a Valgrind tool
which monitors operations on a user-specified region of memory. Basically,
a watchpoint on steroids.
I want my analysis of a memory region to be active when, and only when, the
function in which one of my memory-watches is defined is present on the
callstack. Consider this example:
///////////// BEGIN EXAMPLE /////////////
1: // C is a mystery function.
2: // It might even recursively call B().
3: extern void C( int* );
4:
5: void B() {
6: int X = 42;
7: int Y = 100;
8: C( &X );
9: }
10:
11: void A() {
12: for (int i = 0; i < 1000; ++i) {
13: B();
14: }
15: }
I'd like to be able to define a quasi-watchpoint such as "the variable X in
function B".
For each activation of function "B", I want my Valgrind tool to be notified
with the numeric address range occupied by that frame's instance of "B".
I also want my Valgrind tool to be notified each time function "B" returns,
so it can deactivate the memory-watching that was established when that
stack frame was created.
The loop in function A() to point out that it's not always practical for a
human to perform the conversion from the symbolic
naming of the memory to be evaluated ("X in function B()") to a specific
numeric address.
///////////// END EXAMPLE /////////////
I do not think I can perform the kinds of analyses I want entirely within
GDB, even using its Python API. GDB hardware watchpoints can't handle the
sizes of memory regions I want to analyze, and gdb software breakpoints are
too slow for my needs.
I also believe that none of the currently available Valgrind tools performs
the kind of memory-operation analyses I want to do. I think Valgrind is
the right framework for what I want to do, but AFAICT I'll want to write a
new tool.
So my challenge is to somehow get GDB's help in converting an lvalue
expression like the one mentioned above, into a form that a Valgrind tool
can make sense of.
At the moment I'm looking to do this with a combination of:
* Running GDB commands at GDB breakpoints, and
* Having those commands send the relevant information, including
numeric (not symbolic) address ranges to my tool via `gdb monitor`).
I think this approach is workable, but I'd like to avoid adding
code/scripts to BOTH Valgrind and GDB.
>> * "VG_(get_data_description)" seems to be on the right track,
>> because it searches (nearby) stack frames as well as global variables.
> Yes, this is basically what it does (address to 'symbol').
>> But it seems designed for address-to-symbol translation (I need the
>> opposite), and it doesn't sound smart about C's rules regarding
>> identifier scoping, etc.
> Not too sure what you mean about identifier scoping. It searches
> global and stack variables, taking the C rules into account
> (as these are implied by the stack structure that it scans).
AFAIK, resolving a C identifier should never need to involve looking at the
variables/parameters of any stack frame other than the current one. Since
the docs for "VG_(get_data_description)" mentioned looking at additional
stack frames, I assumed that routine implements something other than the
C-language's resolution rules.
>>
>> I have two backup plans, but I don't love either of them:
>>
>> * I can resolve the symbol myself, using debug info and the current
>> state of the call stack. (I've never done this, but I assume it's not
>> too hard.) Or,
> IMO this is hard :).
Thanks very much for the warning! I will henceforth be less cavalier about
that option :)
- Christian
|
|
From: Philippe W. <phi...@sk...> - 2016-07-26 20:11:02
|
On Tue, 2016-07-26 at 14:04 -0400, Christian Convey wrote:
> Hi guys,
>
> I'm writing my first Valgrind tool, and I'm unsure of the best way to
> get something done. Any suggestions?
>
> Suppose I have a simple target program like this:
>
> int main( int argc, const char* argv[] ) {
> int x = 42;
> return 0;
> }
>
>
> I want my tool to have this functionality: When the program's
> execution is paused at the "return 0;" statement, the user can enter
> this command, which my tool receives via vgdbserver:
> monitor foo x
>
> When my tool's gdb-monitor handler is invoked with the "foo x"
> argument, it should resolve the memory-address, size, and content of
> the inferior's variable "x".
I am not sure to understand why you need a Valgrind tool to do that.
If you are busy debugging an executable,
then gdb can give you the address and content of global variables,
function arguments and local variables.
So, e.g. for the above, you could in gdb do:
p &x
or
info address x
(this last one will rather explain how the address is computed e.g. by
giving the DWARF expression).
The size can be found using p sizeof(x)
And of course, the content using p x
(of course, the above gdb functionalities are working for a native
debugging, but also for a debugging session with the Valgrind gdbserver:
all these commands are implemented at gdb side, not at gdbserver side).
Some valgrind tools (typically memcheck) allows to give a more detailed
description of malloc-ed memory (i.e. where it was allocated), while
gdb has no such feature by itself.
So, unclear why you need a tool, but I am still giving some feedback
below.
>
> I saw some promising leads, but none of them looks like what I want:
>
> * "v.translate" seems designed to translate from a numeric address
> to a symbolic address, but not vice versa.
v.translate is not related to variables or so, but rather to the JIT
compiler part of Valgrind: it shows the translation and instrumentation
of the code instructions at the given address.
>
> * "VG_(strtok_get_address_and_size)" only performs simple
> string-to-number parsing.
Yes, simple parsing.
>
> * "VG_(get_data_description)" seems to be on the right track,
> because it searches (nearby) stack frames as well as global variables.
Yes, this is basically what it does (address to 'symbol').
> But it seems designed for address-to-symbol translation (I need the
> opposite), and it doesn't sound smart about C's rules regarding
> identifier scoping, etc.
Not too sure what you mean about identifier scoping. It searches
global and stack variables, taking the C rules into account
(as these are implied by the stack structure that it scans).
>
> * "pub_tool_debuginfo.h" doesn't appear to have what I need, and
> (even if it were okay for a tool to #include it) neither does
> "pub_core_debuginfo.h".
Yes, pub_tool_*.h can be included by tools, and pub_core_*.h are not
supposed to be included.
>
> * Ditto for "pub_tool_gdbserver.h" and "pub_core_gdbserver.h", respectively.
>
> (Another reason I'm doubtful that Valgrind has support for what I want
> is that an example regarding "v.set hostvisibility" shows a user
> having to manually resolve a C-language lvalue expression into a
> numeric address,length pair.)
v.set hostvisibility is to allow to look at (some) aspects of
the valgrind host state while using gdb also for debugging the guest
(this hostvisibility is however limited to global variables, as host
stack is not made visible to gdb).
Unclear what you mean with this resolve C-language lvalue as
part of v.set hostvisibility
>
> I have two backup plans, but I don't love either of them:
>
> * I can resolve the symbol myself, using debug info and the current
> state of the call stack. (I've never done this, but I assume it's not
> too hard.) Or,
IMO this is hard :).
A.o. you need to read the debug info, dwarf etc,
and then you need to use this to compute where is x,
using whatever info needed e.g. by the dwarf expression
(e.g. registers).
Basically, a non trivial part of gdb (or in some part of
Valgrind debug info and dwarf reader).
>
> * I can write a custom GDB command (i.e., in gdb's scripting
> language, or using Python), which uses GDB's facilities for converting
> the string "x" to a numeric address,length pair, and then provides
> that numeric pair to my Valgrind tool's "monitor" handler. The main
> downside I see to this is that my end users will (I think) need to
> take the additional step of making this custom command available to
> their GDB sessions.
>
> Any suggestions would be greatly appreciated. Thanks!
As said above, basically, unclear why the gdb standard features are
not good enough for what you want to do.
Maybe I misunderstood your objective ?
Or maybe the 'monitor foo x' description above is incomplete
and foo supposed to do more than just give address/content/size of x ?
Philippe
|
|
From: Christian C. <chr...@gm...> - 2016-07-26 18:04:33
|
Hi guys,
I'm writing my first Valgrind tool, and I'm unsure of the best way to
get something done. Any suggestions?
Suppose I have a simple target program like this:
int main( int argc, const char* argv[] ) {
int x = 42;
return 0;
}
I want my tool to have this functionality: When the program's
execution is paused at the "return 0;" statement, the user can enter
this command, which my tool receives via vgdbserver:
monitor foo x
When my tool's gdb-monitor handler is invoked with the "foo x"
argument, it should resolve the memory-address, size, and content of
the inferior's variable "x".
I saw some promising leads, but none of them looks like what I want:
* "v.translate" seems designed to translate from a numeric address
to a symbolic address, but not vice versa.
* "VG_(strtok_get_address_and_size)" only performs simple
string-to-number parsing.
* "VG_(get_data_description)" seems to be on the right track,
because it searches (nearby) stack frames as well as global variables.
But it seems designed for address-to-symbol translation (I need the
opposite), and it doesn't sound smart about C's rules regarding
identifier scoping, etc.
* "pub_tool_debuginfo.h" doesn't appear to have what I need, and
(even if it were okay for a tool to #include it) neither does
"pub_core_debuginfo.h".
* Ditto for "pub_tool_gdbserver.h" and "pub_core_gdbserver.h", respectively.
(Another reason I'm doubtful that Valgrind has support for what I want
is that an example regarding "v.set hostvisibility" shows a user
having to manually resolve a C-language lvalue expression into a
numeric address,length pair.)
I have two backup plans, but I don't love either of them:
* I can resolve the symbol myself, using debug info and the current
state of the call stack. (I've never done this, but I assume it's not
too hard.) Or,
* I can write a custom GDB command (i.e., in gdb's scripting
language, or using Python), which uses GDB's facilities for converting
the string "x" to a numeric address,length pair, and then provides
that numeric pair to my Valgrind tool's "monitor" handler. The main
downside I see to this is that my end users will (I think) need to
take the additional step of making this custom command available to
their GDB sessions.
Any suggestions would be greatly appreciated. Thanks!
- Christian
|