2e62ab400f
Introduce a new print setting max-depth which can be set with 'set print max-depth DEPTH'. The default value of DEPTH is 20, but this can also be set to unlimited. When GDB is printing a value containing nested structures GDB will stop descending at depth DEPTH. Here is a small example: typedef struct s1 { int a; } s1; typedef struct s2 { s1 b; } s2; typedef struct s3 { s2 c; } s3; typedef struct s4 { s3 d; } s4; s4 var = { { { { 3 } } } }; The following table shows how various depth settings affect printing of 'var': | Depth Setting | Result of 'p var' | |---------------+--------------------------------| | Unlimited | $1 = {d = {c = {b = {a = 3}}}} | | 4 | $1 = {d = {c = {b = {a = 3}}}} | | 3 | $1 = {d = {c = {b = {...}}}} | | 2 | $1 = {d = {c = {...}}} | | 1 | $1 = {d = {...}} | | 0 | $1 = {...} | Only structures, unions, and arrays are replaced in this way, scalars and strings are not replaced. The replacement is counted from the level at which you print, not from the top level of the structure. So, consider the above example and this GDB session: (gdb) set print max-depth 2 (gdb) p var $1 = {d = {c = {...}}} (gdb) p var.d $2 = {c = {b = {...}}} (gdb) p var.d.c $3 = {b = {a = 3}} Setting the max-depth to 2 doesn't prevent the user from exploring deeper into 'var' by asking for specific sub-fields to be printed. The motivation behind this feature is to try and give the user more control over how much is printed when examining large, complex data structures. The default max-depth of 20 means that there is a change in GDB's default behaviour. Someone printing a data structure with 20 levels of nesting will now see '{...}' instead of their data, they would need to adjust the max depth, or call print again naming a specific field in order to dig deeper into their data structure. If this is considered a problem then we could increase the default, or even make the default unlimited. This commit relies on the previous commit, which added a new field to the language structure, this new field was a string that contained the pattern that should be used when a structure/union/array is replaced in the output, this allows languages to use a syntax that is more appropriate, mostly this will be selecting the correct types of bracket '(...)' or '{...}', both of which are currently in use. This commit should have no impact on MI output, expressions are printed through the MI using -var-create and then -var-list-children. As each use of -var-list-children only ever displays a single level of an expression then the max-depth setting will have no impact. This commit also adds the max-depth mechanism to the scripting language pretty printers following basically the same rules as for the built in value printing. One quirk is that when printing a value using the display hint 'map', if the keys of the map are structs then GDB will hide the keys one depth level after it hides the values, this ensures that GDB produces output like this: $1 = map_object = {[{key1}] = {...}, [{key2}] = {...}} Instead of this less helpful output: $1 = map_object = {[{...}] = {...}, [{...}] = {...}} This is covered by the new tests in gdb.python/py-nested-maps.exp. gdb/ChangeLog: * cp-valprint.c (cp_print_value_fields): Allow an additional level of depth when printing anonymous structs or unions. * guile/scm-pretty-print.c (gdbscm_apply_val_pretty_printer): Don't print either the top-level value, or the children if the max-depth is exceeded. (ppscm_print_children): When printing the key of a map, allow one extra level of depth. * python/py-prettyprint.c (gdbpy_apply_val_pretty_printer): Don't print either the top-level value, or the children if the max-depth is exceeded. (print_children): When printing the key of a map, allow one extra level of depth. * python/py-value.c (valpy_format_string): Add max_depth keyword. * valprint.c: (PRINT_MAX_DEPTH_DEFAULT): Define. (user_print_options): Initialise max_depth field. (val_print_scalar_or_string_type_p): New function. (val_print): Check to see if the max depth has been reached. (val_print_check_max_depth): Define new function. (show_print_max_depth): New function. (_initialize_valprint): Add 'print max-depth' option. * valprint.h (struct value_print_options) <max_depth>: New field. (val_print_check_max_depth): Declare new function. * NEWS: Document new feature. gdb/doc/ChangeLog: * gdb.texinfo (Print Settings): Document 'print max-depth'. * guile.texi (Guile Pretty Printing API): Document that 'print max-depth' can effect the display of a values children. * python.texi (Pretty Printing API): Likewise. (Values From Inferior): Document max_depth keyword. gdb/testsuite/ChangeLog: * gdb.base/max-depth.c: New file. * gdb.base/max-depth.exp: New file. * gdb.python/py-nested-maps.c: New file. * gdb.python/py-nested-maps.exp: New file. * gdb.python/py-nested-maps.py: New file. * gdb.python/py-format-string.exp (test_max_depth): New proc. (test_all_common): Call test_max_depth. * gdb.fortran/max-depth.exp: New file. * gdb.fortran/max-depth.f90: New file. * gdb.go/max-depth.exp: New file. * gdb.go/max-depth.go: New file. * gdb.modula2/max-depth.exp: New file. * gdb.modula2/max-depth.c: New file. * lib/gdb.exp (get_print_expr_at_depths): New proc. |
||
---|---|---|
.. | ||
lib | ||
guile-internal.h | ||
guile.c | ||
guile.h | ||
README | ||
scm-arch.c | ||
scm-auto-load.c | ||
scm-block.c | ||
scm-breakpoint.c | ||
scm-cmd.c | ||
scm-disasm.c | ||
scm-exception.c | ||
scm-frame.c | ||
scm-gsmob.c | ||
scm-iterator.c | ||
scm-lazy-string.c | ||
scm-math.c | ||
scm-objfile.c | ||
scm-param.c | ||
scm-ports.c | ||
scm-pretty-print.c | ||
scm-progspace.c | ||
scm-safe-call.c | ||
scm-string.c | ||
scm-symbol.c | ||
scm-symtab.c | ||
scm-type.c | ||
scm-utils.c | ||
scm-value.c |
README for gdb/guile
====================
This file contains important notes for gdb/guile developers.
["gdb/guile" refers to the directory you found this file in]
Nomenclature:
In the implementation we use "Scheme" or "Guile" depending on context.
And sometimes it doesn't matter.
Guile is Scheme, and for the most part this is what we present to the user
as well. However, to highlight the fact that it is Guile, the GDB commands
that invoke Scheme functions are named "guile" and "guile-repl",
abbreviated "gu" and "gr" respectively.
Co-existence with Python:
Keep the user interfaces reasonably consistent, but don't shy away from
providing a clearer (or more Scheme-friendly/consistent) user interface
where appropriate.
Additions to Python support or Scheme support don't require corresponding
changes in the other scripting language.
Scheme-wrapped breakpoints are created lazily so that if the user
doesn't use Scheme s/he doesn't pay any cost.
Importing the gdb module into Scheme:
To import the gdb module:
(gdb) guile (use-modules (gdb))
If you want to add a prefix to gdb module symbols:
(gdb) guile (use-modules ((gdb) #:renamer (symbol-prefix-proc 'gdb:)))
This gives every symbol a "gdb:" prefix which is a common convention.
OTOH it's more to type.
Implementation/Hacking notes:
Don't use scm_is_false.
For this C function, () == #f (a la Lisp) and it's not clear how treating
them as equivalent for truth values will affect the GDB interface.
Until the effect is clear avoid them.
Instead use gdbscm_is_false, gdbscm_is_true, gdbscm_is_bool.
There are macros in guile-internal.h to enforce this.
Use gdbscm_foo as the name of functions that implement Scheme procedures
to provide consistent naming in error messages. The user can see "gdbscm"
in the name and immediately know where the function came from.
All smobs contain gdb_smob or chained_gdb_smob as the first member.
This provides a mechanism for extending them in the Scheme side without
tying GDB to the details.
The lifetime of a smob, AIUI, is decided by the containing SCM.
When there is no longer a reference to the containing SCM then the
smob can be GC'd. Objects that have references from outside of Scheme,
e.g., breakpoints, need to be protected from GC.
Don't do something that can cause a Scheme exception inside a TRY_CATCH,
and, in code that can be called from Scheme, don't do something that can
cause a GDB exception outside a TRY_CATCH.
This makes the code a little tricky to write sometimes, but it is a
rule imposed by the programming environment. Bugs often happen because
this rule is broken. Learn it, follow it.
Coding style notes:
- If you find violations to these rules, let's fix the code.
Some attempt has been made to be consistent, but it's early.
Over time we want things to be more consistent, not less.
- None of this really needs to be read. Instead, do not be creative:
Monkey-See-Monkey-Do hacking should generally Just Work.
- Absence of the word "typically" means the rule is reasonably strict.
- The gdbscm_initialize_foo function (e.g., gdbscm_initialize_values)
is the last thing to appear in the file, immediately preceded by any
tables of exported variables and functions.
- In addition to these of course, follow GDB coding conventions.
General naming rules:
- The word "object" absent any modifier (like "GOOPS object") means a
Scheme object (of any type), and is never used otherwise.
If you want to refer to, e.g., a GOOPS object, say "GOOPS object".
- Do not begin any function, global variable, etc. name with scm_.
That's what the Guile implementation uses.
(kinda obvious, just being complete).
- The word "invalid" carries a specific connotation. Try not to use it
in a different way. It means the underlying GDB object has disappeared.
For example, a <gdb:objfile> smob becomes "invalid" when the underlying
objfile is removed from GDB.
- We typically use the word "exception" to mean Scheme exceptions,
and we typically use the word "error" to mean GDB errors.
Comments:
- function comments for functions implementing Scheme procedures begin with
a description of the Scheme usage. Example:
/* (gsmob-aux gsmob) -> object */
- the following comment appears after the copyright header:
/* See README file in this directory for implementation notes, coding
conventions, et.al. */
Smob naming:
- gdb smobs are named, internally, "gdb:foo"
- in Guile they become <gdb:foo>, that is the convention for naming classes
and smobs have rudimentary GOOPS support (they can't be inherited from,
but generics can work with them)
- in comments use the Guile naming for smobs,
i.e., <gdb:foo> instead of gdb:foo.
Note: This only applies to smobs. Exceptions are also named gdb:foo,
but since they are not "classes" they are not wrapped in <>.
- smob names are stored in a global, and for simplicity we pass this
global as the "expected type" parameter to SCM_ASSERT_TYPE, thus in
this instance smob types are printed without the <>.
[Hmmm, this rule seems dated now. Plus I18N rules in GDB are not always
clear, sometimes we pass the smob name through _(), however it's not
clear that's actually a good idea.]
Type naming:
- smob structs are typedefs named foo_smob
Variable naming:
- "scm" by itself is reserved for arbitrary Scheme objects
- variables that are pointers to smob structs are named <char>_smob or
<char><char>_smob, e.g., f_smob for a pointer to a frame smob
- variables that are gdb smob objects are typically named <char>_scm or
<char><char>_scm, e.g., f_scm for a <gdb:frame> object
- the name of the first argument for method-like functions is "self"
Function naming:
General:
- all non-static functions have a prefix,
either gdbscm_ or <char><char>scm_ [or <char><char><char>scm_]
- all functions that implement Scheme procedures have a gdbscm_ prefix,
this is for consistency and readability of Scheme exception text
- static functions typically have a prefix
- the prefix is typically <char><char>scm_ where the first two letters
are unique to the file or class the function works with.
E.g., the scm-arch.c prefix is arscm_.
This follows something used in gdb/python in some places,
we make it formal.
- if the function is of a general nature, or no other prefix works,
use gdbscm_
Conversion functions:
- the from/to in function names follows from libguile's existing style
- conversions from/to Scheme objects are named:
prefix_scm_from_foo: converts from foo to scm
prefix_scm_to_foo: converts from scm to foo
Exception handling:
- functions that may throw a Scheme exception have an _unsafe suffix
- This does not apply to functions that implement Scheme procedures.
- This does not apply to functions whose explicit job is to throw
an exception. Adding _unsafe to gdbscm_throw is kinda superfluous. :-)
- functions that can throw a GDB error aren't adorned with _unsafe
- "_safe" in a function name means it will never throw an exception
- Generally unnecessary, since the convention is to mark the ones that
*can* throw an exception. But sometimes it's useful to highlight the
fact that the function is safe to call without worrying about exception
handling.
- except for functions that implement Scheme procedures, all functions
that can throw exceptions (GDB or Scheme) say so in their function comment
- functions that don't throw an exception, but still need to indicate to
the caller that one happened (i.e., "safe" functions), either return
a <gdb:exception> smob as a result or pass it back via a parameter.
For this reason don't pass back <gdb:exception> smobs for any other
reason. There are functions that explicitly construct <gdb:exception>
smobs. They're obviously the, umm, exception.
Internal functions:
- internal Scheme functions begin with "%" and are intentionally undocumented
in the manual
Standard Guile/Scheme conventions:
- predicates that return Scheme values have the suffix _p and have suffix "?"
in the Scheme procedure's name
- functions that implement Scheme procedures that modify state have the
suffix _x and have suffix "!" in the Scheme procedure's name
- object predicates that return a C truth value are named prefix_is_foo
- functions that set something have "set" at the front (except for a prefix)
write this: gdbscm_set_gsmob_aux_x implements (set-gsmob-aux! ...)
not this: gdbscm_gsmob_set_aux_x implements (gsmob-set-aux! ...)
Doc strings:
- there are lots of existing examples, they should be pretty consistent,
use them as boilerplate/examples
- begin with a one line summary (can be multiple lines if necessary)
- if the arguments need description:
- blank line
- " Arguments: arg1 arg2"
" arg1: blah ..."
" arg2: blah ..."
- if the result requires more description:
- blank line
- " Returns:"
" Blah ..."
- if it's important to list exceptions that can be thrown:
- blank line
- " Throws:"
" exception-name: blah ..."