* 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).