mirror of
https://sourceware.org/git/binutils-gdb.git
synced 2024-12-21 04:42:53 +08:00
1a853c5224
"permanent"-ness is currently a property of the breakpoint. But, it should actually be an implementation detail of a _location_. Consider this bit in infrun.c: /* Normally, by the time we reach `resume', the breakpoints are either removed or inserted, as appropriate. The exception is if we're sitting at a permanent breakpoint; we need to step over it, but permanent breakpoints can't be removed. So we have to test for it here. */ if (breakpoint_here_p (aspace, pc) == permanent_breakpoint_here) { if (gdbarch_skip_permanent_breakpoint_p (gdbarch)) gdbarch_skip_permanent_breakpoint (gdbarch, regcache); else error (_("\ The program is stopped at a permanent breakpoint, but GDB does not know\n\ how to step past a permanent breakpoint on this architecture. Try using\n\ a command like `return' or `jump' to continue execution.")); } This will wrongly skip a non-breakpoint instruction if we have a multiple location breakpoint where the whole breakpoint was set to "permanent" because one of the locations happened to be permanent, even if the one GDB is resuming from is not. Related, because the permanent breakpoints are only marked as such in init_breakpoint_sal, we currently miss marking momentary breakpoints as permanent. A test added by a following patch trips on that. Making permanent-ness be per-location, and marking locations as such in add_location_to_breakpoint, the natural place to do this, fixes this issue... ... and then exposes a latent issue with mark_breakpoints_out. It's clearing the inserted flag of permanent breakpoints. This results in assertions failing like this: Breakpoint 1, main () at testsuite/gdb.base/callexit.c:32 32 return 0; (gdb) call callexit() [Inferior 1 (process 15849) exited normally] gdb/breakpoint.c:12854: internal-error: allegedly permanent breakpoint is not actually inserted A problem internal to GDB has been detected, further debugging may prove unreliable. The call dummy breakpoint, which is a momentary breakpoint, is set on top of a manually inserted breakpoint instruction, and so is now rightfully marked as a permanent breakpoint. See "Write a legitimate instruction at the point where the infcall breakpoint is going to be inserted." comment in infcall.c. Re. make_breakpoint_permanent. That's only called by solib-pa64.c. Permanent breakpoints were actually originally invented for HP-UX [1]. I believe that that call (the only one in the tree) is unnecessary nowadays, given that nowadays the core breakpoints code analyzes the instruction under the breakpoint to automatically detect whether it's setting a breakpoint on top of a breakpoint instruction in the program. I know close to nothing about HP-PA/HP-UX, though. [1] https://sourceware.org/ml/gdb-patches/1999-q3/msg00245.html, and https://sourceware.org/ml/gdb-patches/1999-q3/msg00242.html In addition to the per-location issue, "permanent breakpoints" are currently always displayed as enabled=='n': (gdb) b main Breakpoint 3 at 0x40053c: file ../../../src/gdb/testsuite/gdb.arch/i386-permbkpt.S, line 29. (gdb) info breakpoints Num Type Disp Enb Address What 3 breakpoint keep n 0x000000000040053c ../../../src/gdb/testsuite/gdb.arch/i386-permbkpt.S:29 But OTOH they're always enabled; there's no way to disable them... In turn, this means that if one adds commands to such a breakpoint, they're _always_ run: (gdb) start Starting program: /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.arch/i386-permbkpt ... Temporary breakpoint 1, main () at ../../../src/gdb/testsuite/gdb.arch/i386-permbkpt.S:29 29 int3 (gdb) b main Breakpoint 2 at 0x40053c: file ../../../src/gdb/testsuite/gdb.arch/i386-permbkpt.S, line 29. (gdb) info breakpoints Num Type Disp Enb Address What 2 breakpoint keep n 0x000000000040053c ../../../src/gdb/testsuite/gdb.arch/i386-permbkpt.S:29 (gdb) commands Type commands for breakpoint(s) 2, one per line. End with a line saying just "end". >echo "hello!" >end (gdb) disable 2 (gdb) start The program being debugged has been started already. Start it from the beginning? (y or n) y Temporary breakpoint 3 at 0x40053c: file ../../../src/gdb/testsuite/gdb.arch/i386-permbkpt.S, line 29. Starting program: /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.arch/i386-permbkpt Breakpoint 2, main () at ../../../src/gdb/testsuite/gdb.arch/i386-permbkpt.S:29 29 int3 "hello!"(gdb) IMO, one should be able to disable such a breakpoint, and GDB should then behave just like if the user hadn't created the breakpoint in the first place (that is, report a SIGTRAP). By making permanent-ness a property of the location, and eliminating the bp_permanent enum enable_state state ends up fixing that as well. No tests are added for these changes yet; they'll be added in a follow up patch, as skipping permanent breakpoints is currently broken and trips on an assertion in infrun. Tested on x86_64 Fedora 20, native and gdbserver. gdb/ChangeLog: 2014-11-12 Pedro Alves <palves@redhat.com> Mark locations as permanent, not the whole breakpoint. * breakpoint.c (remove_breakpoint_1, remove_breakpoint): Adjust. (mark_breakpoints_out): Don't mark permanent breakpoints as uninserted. (breakpoint_init_inferior): Use mark_breakpoints_out. (breakpoint_here_p): Adjust. (bpstat_stop_status, describe_other_breakpoints): Remove handling of permanent breakpoints. (make_breakpoint_permanent): Mark each location as permanent, instead of marking the breakpoint. (add_location_to_breakpoint): If the location is permanent, mark it as such, and as inserted. (init_breakpoint_sal): Don't make the breakpoint permanent here. (bp_location_compare, update_global_location_list): Adjust. (update_breakpoint_locations): Don't make the breakpoint permanent here. (disable_breakpoint, enable_breakpoint_disp): Don't skip permanent breakpoints. * breakpoint.h (enum enable_state) <bp_permanent>: Delete field. (struct bp_location) <permanent>: New field. * guile/scm-breakpoint.c (bpscm_enable_state_to_string): Remove reference to bp_permanent. |
||
---|---|---|
.. | ||
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 ..."