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]
Other format: [Raw text]

Re: Catchpoint in GDB/MI


> 
> On Tue, May 06, 2003 at 11:15:50AM -0400, Alain Magloire wrote:
> > > 
> > > On Tue, May 06, 2003 at 10:50:47AM -0400, Alain Magloire wrote:
> > > > Bonjour
> > > > 
> > > > 	Anyone working on putting catchpoints in GDB/MI.
> > > > If yes what is the semantics.
> > > > If no what is the best semantic?  Completely OOB:
> > > > 
> > > > -catch load
> > > > ^done
> > > > ...
> > > > 
> > > > *stop,reason="shared-loaded",shared="libm.so"
> > > 
> > > Do we even have any targets besides HP/UX where shared library
> > > catchpoints _work_?
> > 
> > Probably none, in the gdb source tree.  For example, catching exceptions
> > is probably compiler dependent 8-( .. I think.  Do remember Daniel Berlin
> > proposing a scheme for gcc long long time ago, could not retrace the email
> > though ... darn!
> 
> I've actually added catchpoints for exceptions back; but they'll just
> show up as breakpoints for now.  If we want them to show up differently
> someone's going to have to work out (both CLI and MI) what they should
> look like.
> 

Details please? 8-)

Do you mean setting breakpoint on some special function used to throw
exception __raise_exception(..)?

How does it work ?


> > > We need to fix them before we talk about their MI
> > > syntax, IMO.  Similarly for most of the others.
> > > 
> > 
> > True, but there are a lot of MI commands that are define but
> > not implemented in the current tree or rather can not be implemented
> > in a clean way to be submit back.  So not all gdb/mi are equal depending
> > on the distribution.  But having the MI framework already in place is
> > a good step in normalizing(sp?).
> 
> I'm not sure that catchpoints _can_ be normalized.  The ones we have
> now are mostly extremely system dependent.
> 

Yes and with this in mind, I would advocate to put the MI framework/commands
in place  even if they endup throwing "(not implemented)" on many platforms
or c++ compilers.



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