Re: Why try to reuse breakpoint structures?

Amit Kale wrote:
> On Tuesday 10 Jan 2006 6:15 pm, Amit Kale wrote:
>
> > We keep track of removed entries to prevent breakpoints from occuring after
> > they were removed. Removed breakpoints might have occured on other
> > processors before there removal from code, which will pop up on continuing
> > and cause segfaults on i386. kgdb_skipexception function identifies them.
I wonder if this is the best way to do this.  On the x86, at least, the BP 
instruction causes a unique trap into KGDB.  So, it seems to me a check, 
early on, if such a trap occured AND there is no BP instruction at the fault 
location should do the trick.  The reason I bring this up is that it is not 
clear that we can EVER remove an old BP address from the list, i.e. we just 
don't know how long it will take a given cpu to finally get its BP serviced. 
 I suppose we could keep track of cpu entries to KGDB since the BP was 
removed, but this seems rather complex.

George
>

> Removed breakpoints can be placed again, in which case they can't be ignored 
> on other processors. That's why we reuse those entries.
> -Amit
>
>
> > -Amit
> >
> > On Tuesday 10 Jan 2006 6:46 am, Jim Blandy wrote:
> >
> > > When setting a new breakpoint, kgdb_set_sw_break searches kdb_break
> > > for an entry that is bp_disabled, but takes care to re-use disabled
> > > entries whose address matches that of the new breakpoint.  What's the
> > > point?  Aren't all disabled entries the same, that is, just free
> > > space?
> > >
> > >
> > > -------------------------------------------------------
> > > This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> > > files for problems?  Stop!  Download the new AJAX search engine that
> > > makes searching your log files as easy as surfing the  web.  DOWNLOAD
> > > SPLUNK! http://ads.osdn.com/?ad_idv37&alloc_id865&op=Click
> > > _______________________________________________
> > > Kgdb-bugreport mailing list
> > > Kgdb-bugreport@xxxxxxxxxxxxxxxxxxxxx
> > > https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> _______________________________________________
> Kgdb-bugreport mailing list
> Kgdb-bugreport@xxxxxxxxxxxxxxxxxxxxx
> https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport

--
George Anzinger   george@xxxxxxxxxx
HRT (High-res-timers):  http://sourceforge.net/projects/high-res-timers/


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click