Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Phil Muldoon <pmuldoon@redhat.com>
To: Tom Tromey <tromey@redhat.com>
Cc: Joel Brobecker <brobecker@adacore.com>,
	        gdb-patches ml <gdb-patches@sourceware.org>,
	        Eli Zaretskii <eliz@gnu.org>
Subject: Re: [patch][python] Add breakpoint support.
Date: Thu, 08 Apr 2010 21:27:00 -0000	[thread overview]
Message-ID: <4BBE4A34.3020301@redhat.com> (raw)
In-Reply-To: <m3tyrlptjb.fsf@fleche.redhat.com>

On 04/08/2010 09:40 PM, Tom Tromey wrote:
>>>>>> "Phil" == Phil Muldoon <pmuldoon@redhat.com> writes:
> 
> Phil> There is a save_breakpoints.py script in the archer repository
> Phil> already, so a lot of the work is done. I have a patch to modify that
> Phil> to save watchpoints too.  I've not ported it here today as I purely
> Phil> want to concentrate on the API aspect of porting. But there is really
> Phil> no reason why it can't go in immediately as part of another porting
> Phil> effort. I  think it would need some make/configure hackery to install,
> Phil> which is definitely my weakest area.
> 
> I can help with that if you want.

That would be great, thanks.  I'll check the Python breakpoint API
in tomorrow at some point during BST time. So after that, it should be
ok.

> I think the more difficult problem is deciding how users should activate
> commands written in Python.  Right now for Archer we have this "require"
> thing, but that seems like kind of a hack.  OTOH, loading all the
> commands at startup also seems weird.  It will make startup slower, for
> one thing.  Maybe we could implement some kind of auto-loading?

I normally (I think -- it's been awhile) just end up loading these with
execfile in my .gdbinit.  I cannot remember now. Anyway, it is not
optimal.  

Off the cuff, I think some kind of lazy-loading script mechanism would
be neat.  Scripts would register interest (much like the the
pretty-printers do now) in some kind of registry. I guess at start-up
GDB would have to invoke at least script stubs. This would
be so completion could work with Python scripts that are present but
not loaded.  And then, if all internal GDB commands are exhausted on
completion, GDB  could look in the Python script registry for commands
and complete/load them on demand. Or something like that?  I've no
idea how difficult this lazy mechanism would be off-hand.  Making GDB
aware of all Python utility scripts in a library seems nebulous. How?

Cheers,

Phil


  reply	other threads:[~2010-04-08 21:27 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-29 13:52 Phil Muldoon
2010-03-29 14:28 ` Eli Zaretskii
2010-03-29 14:53   ` Phil Muldoon
2010-03-29 15:15     ` Eli Zaretskii
2010-04-05 16:27 ` Joel Brobecker
2010-04-06 13:47   ` Phil Muldoon
2010-04-06 18:21     ` Eli Zaretskii
2010-04-07 21:09     ` Tom Tromey
2010-04-08 12:42       ` Phil Muldoon
2010-04-08 15:29         ` Joel Brobecker
2010-04-08 19:48           ` Phil Muldoon
2010-04-08 20:41             ` Tom Tromey
2010-04-08 21:27               ` Phil Muldoon [this message]
2010-04-08 21:45                 ` Joel Brobecker
2010-04-08 22:21                   ` Pedro Alves
2010-04-08 23:26                     ` Joel Brobecker
2010-04-08 23:40                       ` Pedro Alves
2010-04-09 15:35                       ` Tom Tromey
2010-04-09 15:32                   ` Tom Tromey
2010-04-08 19:57         ` Tom Tromey
2010-04-09 10:11           ` Phil Muldoon
2010-04-07 21:19     ` Joel Brobecker
2010-06-11 17:41     ` Ulrich Weigand
2010-06-11 20:28       ` Phil Muldoon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4BBE4A34.3020301@redhat.com \
    --to=pmuldoon@redhat.com \
    --cc=brobecker@adacore.com \
    --cc=eliz@gnu.org \
    --cc=gdb-patches@sourceware.org \
    --cc=tromey@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox