This is the mail archive of the gdb@sources.redhat.com 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]

Re: GDB/MI how to go from the manual info to nuts and bolts...?



  Hello.

  I'm getting there.  

  It looks like GDB/MI is really meant to be gdb running
as another process.  Is a users application supposed to
invoke it from their code with a "system" or "exec" call,
then interact with it through the stdin and stdout pipes ?

  And what does the "layer below" mean? is there a library
and include file available to actually link to ? 

 I'm working on very large supercomputer applications where
a user does not get access to the computing nodes in an
interactive manner (batch processing, hundreds or thousands
of cpus working through MPI).  A job dies, you don't know
why, you just used up 15% of your processing allocation doing
galactic formation physics and you have no idea what happened.
Do you run again ?  running this kind of code in debug on your
workstation is not an option. one processor says it got an
FPE error, what routine was it ?  

  One option is to compile optimized (because these problems
would take months to run in debug), and discover exactly what
subroutine failed (a stack trace).  instrument the hell out
of that subroutine, and resubmit the batch job and wait for
the results.  It is not interactive (not an option for massive
parallel computing), but it should hopefully minimize the resource
usage.  I would like to put signal handlers in my application
code and have efficient post-mortems created (core files for problems
like this are not advisable, as memory images can run into a terabyte).
I would like to get a stack trace and other program state info.
The only way I can think to do this is invoke a debugger.  It
would be nice to have a libGDB to link with.  when some
errors occur, it will not be advisable to fork a new process
(memory errors, etc.).

Brian

Andrew Cagney wrote:
> 
> Brian wrote:
> >
> >   I've had a read through ot the GDB MI interface manual section , but I
> > still
> > can't figure out what is going on.  There had been talk that this was an
> > attempt
> > to do what libGDB was supposed to do.  So does GDB MI build a library
> > you can link into your application code ?  I've been wanting to have
> > stack
> > trace dump and maybe CLI invocation from a compiled program on error
> > signals and abort
> > calls.    How does the MI make it possible to make gdb part of a larger
> > application ?
> 
> MI gives GDB a well behaved (and extreemly predictable) textual
> interface.  Up until now people have done things like:
> 
>         DDD <-> GDB/CLI + GDB core
> 
> MI changes that to a much more tightly defined:
> 
>         GUI <-> GDB/MI + GDB core
> 
> within MI there is the UI-OUT object.  You've several choices:
> 
>         o       use MI and GDB as a separate
>                 process.
> 
>                 If your GUI is scripting language
>                 based then this is probably the best
>                 move.  If you combine GDB and
>                 the script interpreter in a single
>                 executable then a GDB bug (what never!)
>                 easily crash your larger application.
> 
>                 I believe that this is part of
>                 what the SourceNav people
>                 want to do.
> 
>         o       use the layer below MI and link
>                 in your application directly.
> 
>                 A variation on this is to use the
>                 layer below MI to build an interface
>                 that is specific to your separate
>                 GUI application.
> 
>                 I believe this is the other half of
>                 what the SourceNav people want to do.
>                 (add a tcl specific equivalent to the MI layer
>                 so that GDB<->SN comms is more efficient.)
> 
> Right now, MI development is waiting for a ``customer'' (a GUI wanting
> to use it and drive it further.)
> 
>         Andrew

-- 
Brian Van Straalen           Lawrence Berkeley Lab
BVStraalen@lbl.gov        National Energy Research
(510) 486-7665         Scientific Computing Center

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