Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Tom Tromey <tromey@redhat.com>
To: Kevin Pouget <kevin.pouget@gmail.com>
Cc: gdb@sourceware.org
Subject: Re: Python objfile-gdb.py file -- how to handle reloading properly ?
Date: Wed, 23 Mar 2011 18:26:00 -0000	[thread overview]
Message-ID: <m362r93d8q.fsf@fleche.redhat.com> (raw)
In-Reply-To: <AANLkTi=XEP8x27_BNr6NwS09Ra=nNu=CA6qrrpUJ5N8Z@mail.gmail.com>	(Kevin Pouget's message of "Wed, 23 Mar 2011 04:53:57 -0400")

>>>>> "Kevin" == Kevin Pouget <kevin.pouget@gmail.com> writes:

Kevin> I'm not writing a pretty-printer, but something quite similar to
Kevin> thread-event notification (eg, thread creation/death, where some
Kevin> special locations are breakpointed, and an action is trigger upon
Kevin> hitting the bp).

Sounds cool.

Kevin> So in this case, maybe the autoloading discussed before is not
Kevin> actually the best solution. What I would like to do is:

Kevin> (at gdb startup) Load the process-independent part of my
Kevin> --python-- module

We are currently a bit weak on this part.  We should probably provide a
way for 3rd parties to drop in some Python that is loaded at startup.
I think at least the distros will want this.

Kevin> (at application startup/shared library loading) Set my
Kevin> breakpoint, resolve addresses and enable process-dependent
Kevin> commands

Loading your code can still be done via the objfile hook.  That is a
fine way to load any code associated with an objfile; the documentation
talks about pretty-printers but there is no deep connection there, and
we plan to make it more useful to load other things here (e.g., frame
filters).

It sounds like maybe what you want is to use the new event stuff to get
notifications of events.  I am not sure.  Also, because the event
support is new, there are probably things that would be useful to report
that we currently do not.  File bugs for missing stuff.

Tom


      parent reply	other threads:[~2011-03-23 18:26 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-22 14:07 Kevin Pouget
     [not found] ` <AANLkTikZX2JvZF4bNYh8ZQR-e-bqLS=+zZq_m_b2Y+an@mail.gmail.com>
2011-03-22 15:00   ` Kevin Pouget
2011-03-22 17:00 ` Tom Tromey
     [not found]   ` <AANLkTi=XEP8x27_BNr6NwS09Ra=nNu=CA6qrrpUJ5N8Z@mail.gmail.com>
2011-03-23  9:06     ` Kevin Pouget
     [not found]       ` <AANLkTikp_m_zwsUPmmEvgHiEKxBidNd-MNY4cTrprynU@mail.gmail.com>
     [not found]         ` <AANLkTi=66tRSet6UgrtBpZzEU5o_PmTdazdkB-NnWEVZ@mail.gmail.com>
2011-03-23 10:46           ` Kevin Pouget
2011-03-23 18:26     ` Tom Tromey [this message]

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=m362r93d8q.fsf@fleche.redhat.com \
    --to=tromey@redhat.com \
    --cc=gdb@sourceware.org \
    --cc=kevin.pouget@gmail.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