Discussion:
GDB C API -- does such a thing exist?
(too old to reply)
Ömer Sinan Ağacan
2014-10-16 11:20:25 UTC
Permalink
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.
Phil Muldoon
2014-10-16 12:53:34 UTC
Permalink
Post by Ö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.
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
Joel Brobecker
2014-10-16 13:54:13 UTC
Permalink
Post by Phil Muldoon
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).
Post by Phil Muldoon
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
Jan Kratochvil
2014-10-16 14:06:35 UTC
Permalink
Post by Joel Brobecker
Post by Phil Muldoon
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
Bob Rossi
2014-10-16 14:01:54 UTC
Permalink
Post by Ö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.
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
Jan Kratochvil
2014-10-16 14:09:03 UTC
Permalink
Post by Bob Rossi
If you want to use the GDB/MI interface,
[...]
Post by Bob Rossi
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
Stan Shebs
2014-10-16 23:45:17 UTC
Permalink
Post by Ö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.
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
***@codesourcery.com
Ömer Sinan Ağacan
2014-10-17 06:44:30 UTC
Permalink
Thanks for all the answers.
Post by Stan Shebs
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.
Pedro Alves
2014-10-17 08:08:15 UTC
Permalink
Post by Ömer Sinan Ağacan
Thanks for all the answers.
Post by Stan Shebs
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 .
Post by Ömer Sinan Ağacan
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?
Post by Ömer Sinan Ağacan
So I had a bad impression about it. I'm hoping to be wrong.
Thanks,
Pedro Alves
Pedro Alves
2014-10-17 08:46:51 UTC
Permalink
Post by Pedro Alves
Post by Ömer Sinan Ağacan
Thanks for all the answers.
Post by Stan Shebs
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
Post by Pedro Alves
Post by Ömer Sinan Ağacan
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
Jan Kratochvil
2014-10-17 12:05:55 UTC
Permalink
Post by Ömer Sinan Ağacan
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
Joel Brobecker
2014-10-17 12:28:59 UTC
Permalink
Jan,
Post by Jan Kratochvil
# 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
Bob Rossi
2014-10-17 15:33:05 UTC
Permalink
Post by Joel Brobecker
Jan,
Post by Jan Kratochvil
# 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

Jan Kratochvil
2014-10-17 12:02:50 UTC
Permalink
Post by Stan Shebs
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.
Post by Stan Shebs
and c) gets involved with permissions,
I do not see what you mean there.
Post by Stan Shebs
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.
Post by Stan Shebs
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
Jan Kratochvil
2014-10-17 12:17:06 UTC
Permalink
Post by Stan Shebs
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
Loading...