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]

how to set/catch language-specific internal breakpoints?

To support UPC debugging, breakpoints need to be set in the
runtime at specific places and special actions need to be
taken.  These special breakpoints catch the program being
debugged generally just after the runtime is initialized.
One breakpoint is specific to the "starter" process which
creates all of the sub-processes which in turn implement
UPC "threads".  Each thread process will hit another
internal breakpoint as it "checks in" with debugger,
just prior to executing the user's main program.

Reviewing the code in breakpoint.c, it appears that
this sort of thing is done with "internal breakpoints"?
And to define a new internal breakpoint, we add it to the
breakpoint type enumeration?

What isn't so clear is where/how to intercept the
internal breakpoint so that GDB-UPC can retrieve data
from the procesos (UPC thread) that just stopped, and in
certain cases poke new data into the process (clearing
the debugger "gate" - which tells the runtime that it can
resume execution of the UPC thread).

It looks as if bpstat_do_actions() is called from the main
execution loop to handle actions related to breakpoints.
The main purpose of that routine is to execute user
commands associated with the breakpoint.  Is this the
appropriate place to add checks for the UPC-specific
breakpoint handlers, or is there a more appropriate
mechanism?  Is there code in GDB (perhaps related to
another language dialect) that already does this
sort of thing?

  - Gary

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