* What about add new commands "maintenance agent-breakpoint id expression" and "maintenance agent-eval-breakpoint id expression" @ 2012-06-12 0:15 Hui Zhu 2012-06-12 2:03 ` Yao Qi 2012-06-12 23:36 ` Stan Shebs 0 siblings, 2 replies; 6+ messages in thread From: Hui Zhu @ 2012-06-12 0:15 UTC (permalink / raw) To: gdb Hi guys, The "maintenance agent" and "maintenance agent-eval" are for translate an expression into remote agent bytecode. Both of them got address info from frame. But when we use tracepoint or breakpoint with agent code, this address is from tracepoint or breakpoint. What about add new commands "maintenance agent-breakpoint id expression" and "maintenance agent-eval-breakpoint id expression"? Then we can get the agent code for breakpoint or tracepoint directly. Thanks, Hui ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: What about add new commands "maintenance agent-breakpoint id expression" and "maintenance agent-eval-breakpoint id expression" 2012-06-12 0:15 What about add new commands "maintenance agent-breakpoint id expression" and "maintenance agent-eval-breakpoint id expression" Hui Zhu @ 2012-06-12 2:03 ` Yao Qi 2012-06-12 11:42 ` Hui Zhu 2012-06-12 23:36 ` Stan Shebs 1 sibling, 1 reply; 6+ messages in thread From: Yao Qi @ 2012-06-12 2:03 UTC (permalink / raw) To: Hui Zhu; +Cc: gdb On 06/12/2012 08:15 AM, Hui Zhu wrote: > Hi guys, > > The "maintenance agent" and "maintenance agent-eval" are for translate > an expression into remote agent bytecode. > Both of them got address info from frame. But when we use tracepoint or > breakpoint with agent code, this address is from tracepoint or breakpoint. Agent expression evaluation makes sense in the context of "current scope" or "current frame". We can't switch to a frame at any arbitrary address, because the frame maybe does not exist. Any examples that "maint agent" doesn't meet your needs in breakpoint/tracepoint? It works in the following simple case, (gdb) b main if (unsigned int) main > 1 (gdb) maintenance agent-eval (unsigned int) main > 1 0 const64 134513662 9 zero_ext 32 11 const8 1 13 zero_ext 32 15 swap 16 less_unsigned 17 end -- Yao (é½å°§) ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: What about add new commands "maintenance agent-breakpoint id expression" and "maintenance agent-eval-breakpoint id expression" 2012-06-12 2:03 ` Yao Qi @ 2012-06-12 11:42 ` Hui Zhu 2012-06-12 13:15 ` Yao Qi 0 siblings, 1 reply; 6+ messages in thread From: Hui Zhu @ 2012-06-12 11:42 UTC (permalink / raw) To: Yao Qi; +Cc: Hui Zhu, gdb On Tue, Jun 12, 2012 at 10:02 AM, Yao Qi <yao@codesourcery.com> wrote: > On 06/12/2012 08:15 AM, Hui Zhu wrote: >> Hi guys, >> >> The "maintenance agent" and "maintenance agent-eval" are for translate >> an expression into remote agent bytecode. >> Both of them got address info from frame. But when we use tracepoint or >> breakpoint with agent code, this address is from tracepoint or breakpoint. > > Agent expression evaluation makes sense in the context of "current > scope" or "current frame". We can't switch to a frame at any arbitrary > address, because the frame maybe does not exist. > What your worry about is line "expr = parse_expression (exp);" cannot work, right? It can be change to function "parse_exp_1" to handle this issue. BTW if agent generate need current scope or current frame, how this code generate when breakpoint or tracepoint use it? :) > Any examples that "maint agent" doesn't meet your needs in > breakpoint/tracepoint? It works in the following simple case, > > (gdb) b main if (unsigned int) main > 1 > (gdb) maintenance agent-eval (unsigned int) main > 1 > 0 const64 134513662 > 9 zero_ext 32 > 11 const8 1 > 13 zero_ext 32 > 15 swap > 16 less_unsigned > 17 end > > -- > Yao (齐尧) > > It have too much limit. For example, it will not work when we want collect an local var inside of a function. Thanks, Hui ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: What about add new commands "maintenance agent-breakpoint id expression" and "maintenance agent-eval-breakpoint id expression" 2012-06-12 11:42 ` Hui Zhu @ 2012-06-12 13:15 ` Yao Qi 0 siblings, 0 replies; 6+ messages in thread From: Yao Qi @ 2012-06-12 13:15 UTC (permalink / raw) To: Hui Zhu; +Cc: Hui Zhu, gdb On 06/12/2012 07:41 PM, Hui Zhu wrote: >> > Agent expression evaluation makes sense in the context of "current >> > scope" or "current frame". We can't switch to a frame at any arbitrary >> > address, because the frame maybe does not exist. >> > > What your worry about is line "expr = parse_expression (exp);" cannot > work, right? > It can be change to function "parse_exp_1" to handle this issue. > > BTW if agent generate need current scope or current frame, how this > code generate when breakpoint or tracepoint use it? :) My reply was on the context of "maint agent"/"maint agent-expr" which you asked about. My full reply should be "In 'maint agent'/'maint agent-expr', agent expression evaluation makes in ....". I am not worried about parse_expression, but struct frame_info *fi = get_current_frame (); /* need current scope */ ...... agent = gen_eval_for_expr (get_frame_pc (fi), expr); gives me the feeling that we need a correct frame here. When using variable in condition or actions in breakpoint or tracepoint, the variable should be *visible* under a certain frame (not current frame that we are setting breakpoint/tracepoint, as I observed). > It have too much limit. For example, it will not work when we want > collect an local var inside of a function. It is odd. I can collect a local variable ii in function foo. (gdb) target remote :1234 (gdb) b end Breakpoint 1 at 0x80483c9: file 1.c, line 10. (gdb) trace foo:label Tracepoint 2 at 0x80483c1: file 1.c, line 5. (gdb) actions Enter actions for tracepoint 2, one per line. End with a line saying just "end". >collect ii >end (gdb) tstart (gdb) c Continuing. Breakpoint 1, end () at 1.c:10 10 void end () {} (gdb) tstop (gdb) tfind Found trace frame 0, tracepoint 2 #0 foo () at 1.c:6 6 return ii; (gdb) tdump Data collected at tracepoint 2, trace frame 0: ii = 0 ---- 1.c ---- int foo (void) { int ii = 0; label: return ii; } void end () {} int main (void) { int i = foo (); end (); return 0; } -- Yao (é½å°§) ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: What about add new commands "maintenance agent-breakpoint id expression" and "maintenance agent-eval-breakpoint id expression" 2012-06-12 0:15 What about add new commands "maintenance agent-breakpoint id expression" and "maintenance agent-eval-breakpoint id expression" Hui Zhu 2012-06-12 2:03 ` Yao Qi @ 2012-06-12 23:36 ` Stan Shebs 2012-06-20 10:08 ` Hui Zhu 1 sibling, 1 reply; 6+ messages in thread From: Stan Shebs @ 2012-06-12 23:36 UTC (permalink / raw) To: gdb On 6/11/12 5:15 PM, Hui Zhu wrote: > Hi guys, > > The "maintenance agent" and "maintenance agent-eval" are for translate > an expression into remote agent bytecode. > Both of them got address info from frame. But when we use tracepoint > or breakpoint with agent code, this address is from tracepoint or > breakpoint. > > What about add new commands "maintenance agent-breakpoint id > expression" and "maintenance agent-eval-breakpoint id expression"? > Then we can get the agent code for breakpoint or tracepoint directly. I could see something like that being useful - instead of breakpoint id I would suggest having it take a linespec, so you don't have to create a tracepoint just to see what the bytecodes would be. Also, an optional hyphen-argument like "-at <linespec>" would save defining new maintenance subcommands. One caveat though - not all collect actions translate into agent expressions, so the user could be misled into thinking that the target was running bytecode instead of doing direct collection. (This distinction confused me at least once a while back - the bug was in non-agent collect action.) Stan stan@codesourcery.com ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: What about add new commands "maintenance agent-breakpoint id expression" and "maintenance agent-eval-breakpoint id expression" 2012-06-12 23:36 ` Stan Shebs @ 2012-06-20 10:08 ` Hui Zhu 0 siblings, 0 replies; 6+ messages in thread From: Hui Zhu @ 2012-06-20 10:08 UTC (permalink / raw) To: Stan Shebs; +Cc: gdb On Wed, Jun 13, 2012 at 7:36 AM, Stan Shebs <stanshebs@earthlink.net> wrote: > On 6/11/12 5:15 PM, Hui Zhu wrote: >> >> Hi guys, >> >> The "maintenance agent" and "maintenance agent-eval" are for translate an >> expression into remote agent bytecode. >> Both of them got address info from frame. But when we use tracepoint or >> breakpoint with agent code, this address is from tracepoint or breakpoint. >> >> What about add new commands "maintenance agent-breakpoint id expression" >> and "maintenance agent-eval-breakpoint id expression"? Then we can get the >> agent code for breakpoint or tracepoint directly. > > > I could see something like that being useful - instead of breakpoint id I > would suggest having it take a linespec, so you don't have to create a > tracepoint just to see what the bytecodes would be. Also, an optional > hyphen-argument like "-at <linespec>" would save defining new maintenance > subcommands. > > One caveat though - not all collect actions translate into agent > expressions, so the user could be misled into thinking that the target was > running bytecode instead of doing direct collection. (This distinction > confused me at least once a while back - the bug was in non-agent collect > action.) > > Stan > stan@codesourcery.com > I think the guy that use these commands must be the developer of GDB or the target. I have a strange suggestion that remove these two commands from the gdb.texinfo. :) I will post the patch for add "-at" to these commands later. Best, Hui ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2012-06-20 10:08 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2012-06-12 0:15 What about add new commands "maintenance agent-breakpoint id expression" and "maintenance agent-eval-breakpoint id expression" Hui Zhu 2012-06-12 2:03 ` Yao Qi 2012-06-12 11:42 ` Hui Zhu 2012-06-12 13:15 ` Yao Qi 2012-06-12 23:36 ` Stan Shebs 2012-06-20 10:08 ` Hui Zhu
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).