GDB C API -- does such a thing exist?

GDB C API -- does such a thing exist?

[Ömer Sinan Ağacan]

Do we have a C API for GDB? Something that allows me to run all the
GDB commands/functions that I can run in GDB prompt, but without
messing with GDB prompt?

Python API is not great for what I want to do. I want to run GDB
inside a program, search for some specific currently-running
processes, attach to them, add some breakpoints etc. although all of
those are possible with Python API, 1) I'm not huge fan of the
language 2) I feel like most things would be a lot easier if I could
use a C API that allows me to drive GDB itself.

Thanks.

Re: GDB C API -- does such a thing exist?

[Phil Muldoon]

On 16/10/14 12:20, Ömer Sinan Ağacan wrote:
> Do we have a C API for GDB? Something that allows me to run all the
> GDB commands/functions that I can run in GDB prompt, but without
> messing with GDB prompt?
>
> Python API is not great for what I want to do. I want to run GDB
> inside a program, search for some specific currently-running
> processes, attach to them, add some breakpoints etc. although all of
> those are possible with Python API, 1) I'm not huge fan of the
> language 2) I feel like most things would be a lot easier if I could
> use a C API that allows me to drive GDB itself.

No. Well let me qualify.  There is a libgdb, but I have never used it
and I am not sure anyone has for some many years.  I am not sure how
maintained it is either. Someone else might know more.

A direct C API, aka what we have with Python, while nice, is not
likely any time soon.  We cannot just expose all of the innards of GDB
automatically, say with some script, to a C API.  GDB internals were
never designed to be exposed in such a way.  The API would have to be
a curated API and I don't see anyone working on that goal at present.

If you are determined to go the C route, IMO your best bet would be to
modify GDB directly to your needs and rebuild.  GDB is fairly trivial
to build.  Less so to modify, but those are your options at the
moment. ;)

As it is, for scripting with have Python and Guile based scripting.

Cheers,

Phil

Re: GDB C API -- does such a thing exist?

[Joel Brobecker]

> No. Well let me qualify.  There is a libgdb, but I have never used it
> and I am not sure anyone has for some many years.  I am not sure how
> maintained it is either. Someone else might know more.

I don't think there is a libgdb anymore. IIRC, Jan eliminated it,
because it was increasing the amount of time needed to be linked
(first generate the .a, next build using the .a).

> A direct C API, aka what we have with Python, while nice, is not
> likely any time soon.  We cannot just expose all of the innards of GDB
> automatically, say with some script, to a C API.  GDB internals were
> never designed to be exposed in such a way.  The API would have to be
> a curated API and I don't see anyone working on that goal at present.
> 
> If you are determined to go the C route, IMO your best bet would be to
> modify GDB directly to your needs and rebuild.  GDB is fairly trivial
> to build.  Less so to modify, but those are your options at the
> moment. ;)

Be aware that there is no stability guaranteed in our C API.
Maybe lldb might provide better guarantees in that respect.
I would personally look at either Python or GDB/MI first.

-- 
Joel

Re: GDB C API -- does such a thing exist?

[Jan Kratochvil]

On Thu, 16 Oct 2014 15:54:13 +0200, Joel Brobecker wrote:
> > No. Well let me qualify.  There is a libgdb, but I have never used it
> > and I am not sure anyone has for some many years.  I am not sure how
> > maintained it is either. Someone else might know more.
> 
> I don't think there is a libgdb anymore. IIRC, Jan eliminated it,
> because it was increasing the amount of time needed to be linked
> (first generate the .a, next build using the .a).

I did not eliminate it, one still can run "make libgdb.a".  "libgdb.a" is just
no longer build by default as "libgdb.a" is no longer built as a part of the
"gdb" target to make the build faster.


Jan

Re: GDB C API -- does such a thing exist?

[Jonas Maebe]

On 16 Oct 2014, at 14:53, Phil Muldoon wrote:

> No. Well let me qualify.  There is a libgdb, but I have never used it
> and I am not sure anyone has for some many years.

The Free Pascal Compiler text mode IDE still uses it. It does require  
minor adjustments for every new GDB release though.


Jonas

Re: GDB C API -- does such a thing exist?

[Bob Rossi]

On Thu, Oct 16, 2014 at 02:20:25PM +0300, Ömer Sinan Ağacan wrote:
> Do we have a C API for GDB? Something that allows me to run all the
> GDB commands/functions that I can run in GDB prompt, but without
> messing with GDB prompt?
> 
> Python API is not great for what I want to do. I want to run GDB
> inside a program, search for some specific currently-running
> processes, attach to them, add some breakpoints etc. although all of
> those are possible with Python API, 1) I'm not huge fan of the
> language 2) I feel like most things would be a lot easier if I could
> use a C API that allows me to drive GDB itself.

There is not. Your options are to use the GDB/MI interface or use the
python api.

If you want to use the GDB/MI interface, congratulations, you have to
read and interpret the spec, find all the bugs in it, write a parser
to support all the cases and test it against old and new versions of
GDB. It's a daunting task, I know, I'm working on it.
  https://github.com/brasko/gdbwire
I don't expect to be done implementing and testing this for a long time.

If you want to use the GDB python interface you need to understand that
many GDB deployments do not have the python interpreter built into them.
Also, I'm not sure anyone has successfully tried to control GDB through
the python interface while allowing the user to use the cli interface.
Not sure if this is your goal.

Both of these approaches are possible, but not for the faint of heart.

Good luck!
Bob Rossi

Re: GDB C API -- does such a thing exist?

[Jan Kratochvil]

On Thu, 16 Oct 2014 16:01:54 +0200, Bob Rossi wrote:
> If you want to use the GDB/MI interface,
[...]
>   https://github.com/brasko/gdbwire
> I don't expect to be done implementing and testing this for a long time.

I did not check the project above in detail, it may be a better choice, just
there is also GDB/MI protocol library
	http://sourceforge.net/projects/libmigdb/
which I used with some patches of it in my abandoned
	http://git.jankratochvil.net/?p=gdbmicli.git


Jan

Re: GDB C API -- does such a thing exist?

[Stan Shebs]

On 10/16/14, 4:20 AM, Ömer Sinan Ağacan wrote:
> Do we have a C API for GDB? Something that allows me to run all the
> GDB commands/functions that I can run in GDB prompt, but without
> messing with GDB prompt?
> 
> Python API is not great for what I want to do. I want to run GDB
> inside a program, search for some specific currently-running
> processes, attach to them, add some breakpoints etc. although all of
> those are possible with Python API, 1) I'm not huge fan of the
> language 2) I feel like most things would be a lot easier if I could
> use a C API that allows me to drive GDB itself.

The fact of the situation is that a C API would make things harder, not
easier.  Consider that GDB is a) making system calls, which are
sometimes blocking, b) is doing tricks with signals all over the place,
and c) gets involved with permissions, and d) manages vast quantities
of memory.  It's just not something you ever want in your address space,
like having a drunken malpracticing doctor wandering around your hotel
with a master key and a bagful of scary medical instruments. :-)

MI is really the safe way to go.

Stan
stan@codesourcery.com

Re: GDB C API -- does such a thing exist?

[Ömer Sinan Ağacan]

Thanks for all the answers.

2014-10-17 2:45 GMT+03:00 Stan Shebs <stanshebs@earthlink.net>:
> MI is really the safe way to go.

A lot of people suggested this so I guess that's right. Where can I
find specification of it?

One thing that I'm confused about this MI thing is that even IDEs
don't use it, as far as I can see. For example, I just checked CLion
and it's just running GDB prompt and talking with GDB using it. So I
had a bad impression about it. I'm hoping to be wrong.

Re: GDB C API -- does such a thing exist?

[Pedro Alves]

On 10/17/2014 07:44 AM, Ömer Sinan Ağacan wrote:
> Thanks for all the answers.
> 
> 2014-10-17 2:45 GMT+03:00 Stan Shebs <stanshebs@earthlink.net>:
>> MI is really the safe way to go.
> 
> A lot of people suggested this so I guess that's right. Where can I
> find specification of it?
> 
> One thing that I'm confused about this MI thing is that even IDEs
> don't use it, as far as I can see.

See https://sourceware.org/gdb/wiki/GDB%20Front%20Ends .

> For example, I just checked CLion
> and it's just running GDB prompt and talking with GDB using it. 

How did you check?  Is CLion's source code somewhere?

> So I had a bad impression about it. I'm hoping to be wrong.

Thanks,
Pedro Alves

Re: GDB C API -- does such a thing exist?

[Pedro Alves]

On 10/17/2014 09:08 AM, Pedro Alves wrote:
> On 10/17/2014 07:44 AM, Ömer Sinan Ağacan wrote:
>> Thanks for all the answers.
>>
>> 2014-10-17 2:45 GMT+03:00 Stan Shebs <stanshebs@earthlink.net>:
>>> MI is really the safe way to go.
>>
>> A lot of people suggested this so I guess that's right. Where can I
>> find specification of it?

Sorry, missed responding to this one.  The specification is in the
GDB manual:

  https://sourceware.org/gdb/onlinedocs/gdb/GDB_002fMI.html

>> One thing that I'm confused about this MI thing is that even IDEs
>> don't use it, as far as I can see.
> 
> See https://sourceware.org/gdb/wiki/GDB%20Front%20Ends .

I've now added a Libraries section to this page, and listed the two
C MI wrapper libraries mentioned in this thread, plus a mention
of libgdb.a.  Everyone, feel free to expand this.

Thanks,
Pedro Alves

Re: GDB C API -- does such a thing exist?

[Jonas Maebe]

On 17 Oct 2014, at 10:46, Pedro Alves wrote:

> On 10/17/2014 09:08 AM, Pedro Alves wrote:
>> See https://sourceware.org/gdb/wiki/GDB%20Front%20Ends .
>
> I've now added a Libraries section to this page, and listed the two
> C MI wrapper libraries mentioned in this thread, plus a mention
> of libgdb.a.  Everyone, feel free to expand this.

That page says that Lazarus links to (lib)gdb, but it actually uses  
GDB/MI. It's Free Pascal's own text mode editor (see e.g. http://wiki.lazarus.freepascal.org/File:fp_ubuntu_13_10.png 
  ) that links to libgdb.


Jonas

Re: GDB C API -- does such a thing exist?

[Pedro Alves]

Hi Jonas,

On 10/28/2014 01:30 PM, Jonas Maebe wrote:
> 
> On 17 Oct 2014, at 10:46, Pedro Alves wrote:
> 
>> On 10/17/2014 09:08 AM, Pedro Alves wrote:
>>> See https://sourceware.org/gdb/wiki/GDB%20Front%20Ends .
>>
>> I've now added a Libraries section to this page, and listed the two
>> C MI wrapper libraries mentioned in this thread, plus a mention
>> of libgdb.a.  Everyone, feel free to expand this.
> 
> That page says that Lazarus links to (lib)gdb, but it actually uses  
> GDB/MI. It's Free Pascal's own text mode editor (see e.g. http://wiki.lazarus.freepascal.org/File:fp_ubuntu_13_10.png 
>   ) that links to libgdb.

Could you update the page, please?  I don't really know that
much about those IDEs.

Thanks,
Pedro Alves

Re: GDB C API -- does such a thing exist?

[Jan Kratochvil]

On Fri, 17 Oct 2014 08:44:30 +0200, Ömer Sinan Ağacan wrote:
> One thing that I'm confused about this MI thing is that even IDEs
> don't use it, as far as I can see.

MI is not such a win as I have written in the other mail:

On Fri, 17 Oct 2014 14:02:50 +0200, Jan Kratochvil wrote:
# MI implements only very poor subset of GDB functionality
# so one has to use '-interpreter-exec console ...' anyway and parse the
# unparsable text output.

There is a theoretical suggestion that people should implement into GDB
anything they miss.  But contributability to GDB is difficult for many reasons
besides that it is just an additional barrier to write an MI client (when one
has to write also the MI server along).


Jan

Re: GDB C API -- does such a thing exist?

[Joel Brobecker]

Jan,

> On Fri, 17 Oct 2014 14:02:50 +0200, Jan Kratochvil wrote:
> # MI implements only very poor subset of GDB functionality
> # so one has to use '-interpreter-exec console ...' anyway and parse the
> # unparsable text output.
> 
> There is a theoretical suggestion that people should implement into
> GDB anything they miss.  But contributability to GDB is difficult for
> many reasons besides that it is just an additional barrier to write an
> MI client (when one has to write also the MI server along).

My experience of contributing to GDB/MI does not match yours.
When I worked with the IDE team at AdaCore on GDB/MI, they identified
a number of missing failures, and implementation was both easy and
contribution went well.

-- 
Joel

Re: GDB C API -- does such a thing exist?

[Bob Rossi]

On Fri, Oct 17, 2014 at 05:28:59AM -0700, Joel Brobecker wrote:
> Jan,
> 
> > On Fri, 17 Oct 2014 14:02:50 +0200, Jan Kratochvil wrote:
> > # MI implements only very poor subset of GDB functionality
> > # so one has to use '-interpreter-exec console ...' anyway and parse the
> > # unparsable text output.
> > 
> > There is a theoretical suggestion that people should implement into
> > GDB anything they miss.  But contributability to GDB is difficult for
> > many reasons besides that it is just an additional barrier to write an
> > MI client (when one has to write also the MI server along).
> 
> My experience of contributing to GDB/MI does not match yours.
> When I worked with the IDE team at AdaCore on GDB/MI, they identified
> a number of missing failures, and implementation was both easy and
> contribution went well.

From an outsider perspective, modifying GDB is clearly the right thing
to do, but adds additional barriers to the task at hand. It's difficult
and time consuming, and the changes won't be in the field for years to
come.

Your AdaCore experience probably also coincided with a particular
release of GDB that you distributed. That's easy. You are fortunate.
For the rest of us attempting to deliver a front end to GDB, we have to
consider the version of GDB immaterial. It needs to work across all
variants or determine which features exist per GDB instance. This
is much more complicated. I'm still formulating a plan for this in gdbwire.

I envision the ideal front end client's philosophy as follows:
GDB is the core which produces 2) MI which is sent to 3) gdbwire which 
produces events sent to 4) the front end.

Lets see how much of a reality I can make this.

Thanks,
Bob Rossi

Re: GDB C API -- does such a thing exist?

[Jan Kratochvil]

On Fri, 17 Oct 2014 01:45:17 +0200, Stan Shebs wrote:
> The fact of the situation is that a C API would make things harder, not
> easier.  Consider that GDB is a) making system calls, which are
> sometimes blocking, b) is doing tricks with signals all over the place,

Yes but those are cornercases.

> and c) gets involved with permissions,

I do not see what you mean there.

> and d) manages vast quantities of memory.

What's the problem with multi-process vs. single-process solution?
The problem is that GDB corrupts memory as it is not written in C++.
I was trying to switch GDB to C++ which was rejected and then I at least
posted some -fsanitize=address patches which were ignored.


> MI is really the safe way to go.

The problem with MI is that there is (AFAIK) still no good enough client
library and primarily MI implements only very poor subset of GDB functionality
so one has to use '-interpreter-exec console ...' anyway and parse the
unparsable text output.

Thanks but C API is much easier (C++ would be sure even easier).  LLDB has C++
API but that can never work well for GDB due to GPL of GDB.


Jan

Re: GDB C API -- does such a thing exist?

[Jan Kratochvil]

On Fri, 17 Oct 2014 01:45:17 +0200, Stan Shebs wrote:
> MI is really the safe way to go.

Besides that debugging multi-process apps is a pain.  GDB has no support for
RPC (as remote API calls in general, not SunRPC) calls in any of the RPC
frameworks, moreover GDB does not use any standard RPC library and reinvents
the weel by implementing its own MI protocol + code.

When I wrote some multi-process app (two I remember) I always put there
a switch so that it can run also in-process for debugging purposes.


Jan