This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: reversible debugging, enhancements, proposals


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


----- Original Message ----
From: paawan oza <>
To: Jan Kratochvil <>
Sent: Fri, October 15, 2010 11:12:49 PM
Subject: Re: reversible debugging, enhancements, proposals


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.


----- Original Message ----
From: Jan Kratochvil <>
To: paawan oza <>
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/, 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 
> and most of the user is not predetermined to se where he wants to 

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.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]