Re: reversible debugging, enhancements, proposals

Re: reversible debugging, enhancements, proposals

[paawan oza]

Hi,

The conversation regarding following example and including such feature in gdb 
solely depends on how much gdb community and users assess its importance.
yes there are round about ways of doing it as mentioned in replies, but this 
will add more usability.
it depends on the need and importance I can go ahead working on patch and invest 
some time, 

if it is not important then I can continue with reersible debugging on arm as of 
now : )


Regards,
Oza.



----- Original Message ----
From: paawan oza <paawan1982@yahoo.com>
To: Jan Kratochvil <jan.kratochvil@redhat.com>
Cc: gdb@sourceware.org
Sent: Fri, October 15, 2010 11:12:49 PM
Subject: Re: reversible debugging, enhancements, proposals

Hi,

let me attempt to explain with example.

struct _A
{
     int fl1;
     struct _A *next; 
}

struct _X
{
          int no1;
       struct _A *a; 
       struct _X *next;
}


if commands are provided something like below, rather than having people edit 
the .gdbinit file, script, 'source' command 


gdb> load_link _X  500    (indicates load 500 nodes)
gdb> pview fl1   (print all fl1 values of all nodes)


now this was just an example, it could be supporting any level of nesting, and 
any level of data structure.
the advantage is, user just have to load relevant structure online on gdn prompt 

and ready to view any data any time in any node... rather than playing with 
script and running them and editing them.

In conclusion, I think direct command line interface for such facility is 
convenient and easy to use.

Regards,
Oza.

















----- Original Message ----
From: Jan Kratochvil <jan.kratochvil@redhat.com>
To: paawan oza <paawan1982@yahoo.com>
Cc: gdb@sourceware.org
Sent: Fri, October 15, 2010 8:48:03 PM
Subject: Re: reversible debugging, enhancements, proposals

On Fri, 15 Oct 2010 15:48:57 +0200, paawan oza wrote:
> but my point is: it becomes cumbesome for user to go and modify the 
> file/.gdbinit macro or script.

Projects provide their own .gdbinit files (gcc/gdbinit.in, emacs/src/.gdbinit)
for examining the project's specific data structures.

For example for GList (Gnome glib) it cannot work fully automatically as its
->data is void *.


> you have losts of data streuctures like linked list, complex tree, btree 
>etc....
> and most of the user is not predetermined to se where he wants to look....it 

Maybe a pretty printer could have a hint if one wants to print just a single
element or the whole list?

Or if printing a pointer (and not curretly implemented *pointer) it could
print the whole list?  That may be confusing, though.


Thanks,
Jan


      

reversible debugging, enhancements, proposals

[paawan oza]

Hi,

please give your inputs for following, if required.

1) if we want to debug the long linked list chain, we need to to move manually 
next, next, and so on...
so if you want to to see 100th node's value, or want to know cerain field's 
value in all nodes.... (there also could be level of nesting in the list also, 

for e.g. list->some_field->next  and so on...) then it becomes cumbersome and 
difficult.
I am not sure whether that facility is available, but I think it is a very 
useful feature, if it is not there.

I would like to make a patch which gives that facility in gdb.

2) I also working on arm reversible support (having vmware) that should help me 
finish the insn part (if not linux ABI)... but the work has been going very slow 

: ( 
will try to catch up. 

3) kernel reversible debugging, is there any work going on (such as framework on 
sys call revocation, memory allocation revocation, etc...), just curious to 

know.

Regards,
Oza.


      

Re: reversible debugging, enhancements, proposals

[Jan Kratochvil]

On Fri, 15 Oct 2010 11:30:47 +0200, paawan oza wrote:
> 1) if we want to debug the long linked list chain, we need to to move manually 
> next, next, and so on...
> so if you want to to see 100th node's value, or want to know cerain field's 
> value in all nodes.... (there also could be level of nesting in the list also, 
> 
> for e.g. list->some_field->next  and so on...) then it becomes cumbersome and 
> difficult.
> I am not sure whether that facility is available, but I think it is a very 
> useful feature, if it is not there.

Using this .gdbinit macro:

define plist
	set var $plist_iter=$arg0
	while ($plist_iter)
		if $argc==1
			print *$plist_iter
		else
			if $argc==2
				print $plist_iter->$arg1
			else
				print$arg2 $plist_iter->$arg1
			end
		end
		set var $plist_iter=$plist_iter->next
	end
end
document plist
List dumper iterating by `->next':
plist <head pointer> [<data field to display>] [/<format>]
end


Regards,
Jan

Re: reversible debugging, enhancements, proposals

[paawan oza]

Hi,

yes, I understand that you have mentioned.
perhaps this can be achieved by 'source' command, macros and even probably a 
shell script.

but my point is: it becomes cumbesome for user to go and modify the 
file/.gdbinit macro or script.
it does not provide that facility right on the live terminal (inspecting sort of 
direct machinism such as prin command).

say, for a case,
you have losts of data streuctures like linked list, complex tree, btree etc....
and most of the user is not predetermined to se where he wants to look....it 
would be more comfortable for him if everything he can look on the fly as fast 
and as conveniently as possiblle.

Regards,
Oza.





----- Original Message ----
From: Jan Kratochvil <jan.kratochvil@redhat.com>
To: paawan oza <paawan1982@yahoo.com>
Cc: gdb@sourceware.org
Sent: Fri, October 15, 2010 6:45:34 PM
Subject: Re: reversible debugging, enhancements, proposals

On Fri, 15 Oct 2010 11:30:47 +0200, paawan oza wrote:
> 1) if we want to debug the long linked list chain, we need to to move manually 

> next, next, and so on...
> so if you want to to see 100th node's value, or want to know cerain field's 
> value in all nodes.... (there also could be level of nesting in the list also, 

> 
> for e.g. list->some_field->next  and so on...) then it becomes cumbersome and 
> difficult.
> I am not sure whether that facility is available, but I think it is a very 
> useful feature, if it is not there.

Using this .gdbinit macro:

define plist
    set var $plist_iter=$arg0
    while ($plist_iter)
        if $argc==1
            print *$plist_iter
        else
            if $argc==2
                print $plist_iter->$arg1
            else
                print$arg2 $plist_iter->$arg1
            end
        end
        set var $plist_iter=$plist_iter->next
    end
end
document plist
List dumper iterating by `->next':
plist <head pointer> [<data field to display>] [/<format>]
end


Regards,
Jan



      

Re: reversible debugging, enhancements, proposals

[Jan Kratochvil]

On Fri, 15 Oct 2010 15:48:57 +0200, paawan oza wrote:
> but my point is: it becomes cumbesome for user to go and modify the 
> file/.gdbinit macro or script.

Projects provide their own .gdbinit files (gcc/gdbinit.in, emacs/src/.gdbinit)
for examining the project's specific data structures.

For example for GList (Gnome glib) it cannot work fully automatically as its
->data is void *.


> you have losts of data streuctures like linked list, complex tree, btree etc....
> and most of the user is not predetermined to se where he wants to look....it 

Maybe a pretty printer could have a hint if one wants to print just a single
element or the whole list?

Or if printing a pointer (and not curretly implemented *pointer) it could
print the whole list?  That may be confusing, though.


Thanks,
Jan

Re: reversible debugging, enhancements, proposals

[paawan oza]

Hi,

let me attempt to explain with example.

struct _A
{
     int fl1;
     struct _A *next; 
}

struct _X
{
          int no1;
       struct _A *a; 
       struct _X *next;
}


if commands are provided something like below, rather than having people edit 
the .gdbinit file, script, 'source' command 


gdb> load_link _X  500    (indicates load 500 nodes)
gdb> pview fl1   (print all fl1 values of all nodes)


now this was just an example, it could be supporting any level of nesting, and 
any level of data structure.
the advantage is, user just have to load relevant structure online on gdn prompt 
and ready to view any data any time in any node... rather than playing with 
script and running them and editing them.

In conclusion, I think direct command line interface for such facility is 
convenient and easy to use.

Regards,
Oza.

















----- Original Message ----
From: Jan Kratochvil <jan.kratochvil@redhat.com>
To: paawan oza <paawan1982@yahoo.com>
Cc: gdb@sourceware.org
Sent: Fri, October 15, 2010 8:48:03 PM
Subject: Re: reversible debugging, enhancements, proposals

On Fri, 15 Oct 2010 15:48:57 +0200, paawan oza wrote:
> but my point is: it becomes cumbesome for user to go and modify the 
> file/.gdbinit macro or script.

Projects provide their own .gdbinit files (gcc/gdbinit.in, emacs/src/.gdbinit)
for examining the project's specific data structures.

For example for GList (Gnome glib) it cannot work fully automatically as its
->data is void *.


> you have losts of data streuctures like linked list, complex tree, btree 
>etc....
> and most of the user is not predetermined to se where he wants to look....it 

Maybe a pretty printer could have a hint if one wants to print just a single
element or the whole list?

Or if printing a pointer (and not curretly implemented *pointer) it could
print the whole list?  That may be confusing, though.


Thanks,
Jan



      

Re: reversible debugging, enhancements, proposals

[Tom Tromey]

>>>>> ">" == paawan oza <paawan1982@yahoo.com> writes:

>> 1) if we want to debug the long linked list chain, we need to to move
>> manually next, next, and so on...  so if you want to to see 100th
>> node's value, or want to know cerain field's value in all
>> nodes.... (there also could be level of nesting in the list also,

>> for e.g. list->some_field->next and so on...) then it becomes
>> cumbersome and difficult.  I am not sure whether that facility is
>> available, but I think it is a very useful feature, if it is not
>> there.

>> I would like to make a patch which gives that facility in gdb.

It is simple to write things like this in Python.

You can write a pretty-printer, which is nice for application- or
library-specific cases.  E.g., libstdc++ has a std::list printer that
does this.

Or, you could write a new command that is more general purpose.

Tom