Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
* [PATCH 0/2] Global breakpoints, introduction
@ 2011-06-13 15:58 Stan Shebs
  2011-06-13 16:39 ` Frank Ch. Eigler
  0 siblings, 1 reply; 4+ messages in thread
From: Stan Shebs @ 2011-06-13 15:58 UTC (permalink / raw)
  To: gdb-patches

[-- Attachment #1: Type: text/plain, Size: 2351 bytes --]

This pair of patches plus Linux kernel module adds global breakpoints to 
GDB.  Global breakpoints are installed in multiple processes of a 
target, *including* processes not under GDB control, and processes not 
yet created.  Conceptually, it's similar to breakpoints in some RTOSes 
where tasks share all or part of an address space, and so a breakpoint 
in the shared space will hit in whatever task reaches it first.

In Linux, this is a little more complicated.  We don't want to force 
every process to run under the debugger all the time, and we need to 
catch new processes somehow.  The implementation here uses a kernel 
module that communicates with debuggers via a device /dev/breakpoint.  
In the absence of appropriate internal support in Linux, the module uses 
kprobes to hook into several key spots, and then installs and manages 
breakpoint traps on behalf of the debugger.  When one of these traps is 
hit, the device removes the trap and notifies GDB, which then attaches 
to the process and installs its own breakpoint trap in the usual way.

The user interface adds a "process" keyword to breakpoints, along the 
lines of "thread", so for instance "break mysubr process *" installs a 
breakpoint in all processes using the file in which mysubr is defined 
(which could be either the exec file or a shared library).  "break 
mysubr process future" installs only in processes created after the 
breakpoint is defined.  In addition, combinations and process user/owner 
qualifications are possible, so you can do instant system catatonia with 
something ill-advised like "break malloc process all/root". :-)

The patch here includes both native Linux and remote protocol for Linux 
gdbserver, and I've attached a tgz of the (small) kernel module sources 
to this message.  (The module has only been tested much on the 2.6.35 
kernel.)

This is kind of a freaky addition - it's very cool to see in action, as 
you can catch the first process to call some library function, and it 
will be even more interesting for multicore situations where lots of 
copies of a exec may be running.  At the same time, it pushes the 
envelope on hooking into the system, and in the absence of full 
multi-process infrastructure, the user interface is a little hacky.  So 
I'm open to ideas on how to do all this better.

Stan
stan@codesourcery.com


[-- Attachment #2: bpmodule.tgz --]
[-- Type: application/x-gzip, Size: 11114 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH 0/2] Global breakpoints, introduction
  2011-06-13 15:58 [PATCH 0/2] Global breakpoints, introduction Stan Shebs
@ 2011-06-13 16:39 ` Frank Ch. Eigler
  2011-06-13 17:03   ` Stan Shebs
  0 siblings, 1 reply; 4+ messages in thread
From: Frank Ch. Eigler @ 2011-06-13 16:39 UTC (permalink / raw)
  To: Stan Shebs; +Cc: gdb-patches


Hi, Stan -

stanshebs wrote:

> This pair of patches plus Linux kernel module adds global breakpoints
> to GDB.  [...]

Interesting approach.  Have you been planning to post it to LKML for
review/consideration?

You may want to rebase your code to the LKML uprobes implementation
already under review, so you don't have to duplicate the rather
intricate logic required to safely manage breakpoints in userspace by
the kernel.

- FChE


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH 0/2] Global breakpoints, introduction
  2011-06-13 16:39 ` Frank Ch. Eigler
@ 2011-06-13 17:03   ` Stan Shebs
  2011-06-14  9:39     ` Kevin Pouget
  0 siblings, 1 reply; 4+ messages in thread
From: Stan Shebs @ 2011-06-13 17:03 UTC (permalink / raw)
  To: gdb-patches

On 6/13/11 9:39 AM, Frank Ch. Eigler wrote:
> Hi, Stan -
>
> stanshebs wrote:
>
>> This pair of patches plus Linux kernel module adds global breakpoints
>> to GDB.  [...]
> Interesting approach.  Have you been planning to post it to LKML for
> review/consideration?
>

Yes, I've just been waiting for all the debugger-haters there to retire 
and/or die first. :-)

> You may want to rebase your code to the LKML uprobes implementation
> already under review, so you don't have to duplicate the rather
> intricate logic required to safely manage breakpoints in userspace by
> the kernel.

That's a good idea!  I haven't updated myself on uprobes state in the 
past several months, but you're right, it would be good to have a single 
version of that.

Stan


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH 0/2] Global breakpoints, introduction
  2011-06-13 17:03   ` Stan Shebs
@ 2011-06-14  9:39     ` Kevin Pouget
  0 siblings, 0 replies; 4+ messages in thread
From: Kevin Pouget @ 2011-06-14  9:39 UTC (permalink / raw)
  To: Stan Shebs; +Cc: gdb-patches

Hello,

the idea is very interesting, I'll certainly have to use it soon!

>  fprintf_unfiltered (gdb_stdlog, "target_to_define_global_breakpoint (0x%x, %s, %s, %d) = %d\n",
>		      (int) abfd, paddress (target_gdbarch, addr),
>		      (uname ? uname : "<NULL>"), flags, rslt);

target.c:4200: error: cast from pointer to integer of different size
[-Werror=pointer-to-int-cast]


and in the README, you mention the file "/proc/drivers/breakpoints"
whereas it's certainly /proc/driver/breakpoint


cordially,

Kevin

On Mon, Jun 13, 2011 at 7:03 PM, Stan Shebs <stanshebs@earthlink.net> wrote:
>
> On 6/13/11 9:39 AM, Frank Ch. Eigler wrote:
>>
>> Hi, Stan -
>>
>> stanshebs wrote:
>>
>>> This pair of patches plus Linux kernel module adds global breakpoints
>>> to GDB.  [...]
>>
>> Interesting approach.  Have you been planning to post it to LKML for
>> review/consideration?
>>
>
> Yes, I've just been waiting for all the debugger-haters there to retire and/or die first. :-)
>
>> You may want to rebase your code to the LKML uprobes implementation
>> already under review, so you don't have to duplicate the rather
>> intricate logic required to safely manage breakpoints in userspace by
>> the kernel.
>
> That's a good idea!  I haven't updated myself on uprobes state in the past several months, but you're right, it would be good to have a single version of that.
>
> Stan
>


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2011-06-14  9:39 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-06-13 15:58 [PATCH 0/2] Global breakpoints, introduction Stan Shebs
2011-06-13 16:39 ` Frank Ch. Eigler
2011-06-13 17:03   ` Stan Shebs
2011-06-14  9:39     ` Kevin Pouget

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox