This is the mail archive of the gdb@sourceware.org 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: Keeping breakpoints inserted


Thiago Jung Bauermann <bauerman at br.ibm.com> writes:
> On Thu, 2007-11-29 at 22:24 +0300, Vladimir Prus wrote:
>> Anybody has comments on this approach?
>
> When adding and removing breakpoints, will GDB stop all threads or just
> the one under inspection?
>
> On first thought, I think that if adding a breakpoint can be done
> atomically (i.e., trap instruction is 1 word wide), then it wouldn't be
> necessary to stop other threads. Am I being too naive here? 

The Linux kernel has a facility called 'kprobes' (which is extremely
cool, BTW) that can insert breakpoint instructions into kernel code
while other processors are executing it.  This interface has been
implemented on many different architectures.  We're using it as our
model, since it does essentially what we need to do, in an even more
challenging context.  I haven't seen one where it needs to halt all
other processors while inserting the breakpoint.

On the i386, you pretty much just save the underlying instruction and
drop the trap in.  There are processor errata (AH 33 in
ftp://download.intel.com/design/mobile/SPECUPDT/31407915.pdf) that
warn against the dangers of one processor making changes in another's
code stream, but it turns out that the 'int3' instruction --- the one
used for breakpoints --- is specifically excluded from those errata;
so we're off the hook.


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