[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#30151: Debugger API
From: |
James Nguyen |
Subject: |
bug#30151: Debugger API |
Date: |
Sun, 21 Jan 2018 11:16:22 -0800 |
Thanks, I've submitted an issue here ->
https://github.com/realgud/realgud/issues/206.
Looking at some old code I did when adding breakpoints for lldb, it looks like
I just used the marker-filter and matched against strings in the filter looking
for 'breakpoint print' strings and extracting the info out after.
That might be similar to how something like flymake/flycheck runs a *something*
in a separate process and then matches strings against the output to get the
error output out.
E.g. http://ix.io/EsZ (meant just for discussion)
I'm not sure how we can better support this flow (or if it's even a good idea)
but from what I've seen the marker-filter is the one place where we can
'extract' information from the underlying debugger (using its output).
--
James Nguyen
james@jojojames.com
On Fri, Jan 19, 2018, at 2:19 AM, Eli Zaretskii wrote:
> > From: James Nguyen <james@jojojames.com>
> > Cc: 30151@debbugs.gnu.org
> > Date: Fri, 19 Jan 2018 01:25:47 -0800
> >
> > Ideally, it'd be nice to have something simple that asks me:
> > 1. Where to draw breakpoints in the buffer.
> > 2. What locals exist and displaying them in some kind of 'locals' buffer.
> > 3. Maybe an extra window that will display extraneous information (similar
> > to jdibug's stacktrace buffer)
> > 4. I'm missing some other common functionalities between debuggers.
> >
> > I think some/all of ^ is very similar to gdb-many-windows but I've only
> > ever seen that for *just* gdb.
>
> I agree, but as I said, these capabilities need to be supported by the
> underlying debuggers. Currently, only gdb-mi.el provides them because
> GDB includes a special interface for debugging front-ends, and that
> interface provides the functionality required for the features shown
> in gdb-many-windows. If other debuggers can support similar
> functionalities, gud.el could be extended to do that for them as well.
>
> Perhaps the first step would be to look at what realgud does to
> provide these features. But please be aware that if you are going to
> read realgud's source with the intent of doing something similar in
> Emacs, you are advised to check with realgud's developers whether they
> will be willing to sign legal paperwork, in case you end up copying
> some of their code.
>
> Thanks.