Using C++ code inside gdb

[Duane Ellis]

> On Oct 8, 2015, at 8:20 PM, Ashutosh <ashutoshpal2006@gmail.com> wrote:
> 
> Hi Klaus,
> 
> Thanks for your reply. Actually, I want to extend gdb to support
> targets with multiple memories and for that I wanted to add this
> module inside gdb code. This module would be called from with-in the
> gdb code, for example, when a user prints a variable on the
> command-line, gdb before issuing a request to the target to read the
> corresponding memory address, would first call my module to get some
> memory-specific info. And, I want the module to be contained inside a
> namespace like C++ class. So, basically, I want to add C++ code inside
> the gdb code and was looking for any guidelines/caveats regarding the
> same.


Why do you think this is important? What problem does this solve?

I ask this, because generally - GDB already supports this some what already

For example in the GDB remote case, GDB attempts to read (or write) the target, and the target replies with an ERROR

GDB happens to handle this very well.

In the LINUX case,  you could have a pointer that points at a “random crazy address” - this is normal, if the pointer is not initialized.
Assume you have a GUI front end (like Eclipse) you mouse over over the pointer, and it tries to pop up the content of the pointer

This is by design… 

My question is: Why do you want to do this? What problem are you trying to solve?

=======

GDB 7.9.1  Generally has this sort of support now, very common in the embedded world.

look in the GDB file: “gdb/remote.c”
Also source file called:  gdb/memory-map.c 

Specifically search for this snip of code, this asks a remote target for the “target xml memory map"

    case TARGET_OBJECT_MEMORY_MAP:
      gdb_assert (annex == NULL);
      return remote_read_qxfer (ops, "memory-map", annex, readbuf, offset, len,
				 xfered_len,
				&remote_protocol_packets[PACKET_qXfer_memory_map]);

This existing feature is used in the embedded world to handle programing FLASH memory in a micro controller and has existed for quite some time.

=========

I did this quite a few years ago for an internal version of GDB … things may have changed
but the general process is this:

1)  You’ll also need to wrap various GDB header files with extern “C”” statements

2) I’m not sure if GDB is linked with “g++” or “gcc” - if it is using gcc you must change the build system to use g++ instead. If you do not, your C++ constructors will not work very well.

3)  you’ll also have to add various autoconf features for C++ compilation (if required)

4) And add various rules to the Makefile system.

Start with something *REALLY* simple - 

	Create a simple C++ class, and have it statically initialize it self.
	In the constructor do a simple “printf()” or 
		Create a file like: “testing-duane.txt" and write data to it, the close the file
	In effect, this is a “Hello world” from a static constructor in GDB

	Somewhere in the startup sequence in GDB -
		 call a C function that in turn calls another constructor for another simple object.
		Print some messages, or create a simple text file

	In effect, this is a “Hello world” from a dynamic constructor in GDB

WHY do I say create a simple text file
	Some things modify the STDOUT so that it can be captured
	Depending on where you put your code, “stdout” might be in an odd ball state.
	Thus - if you create a file it will not be in an odd ball state.
	This just simplifies things - thats all.

Make these two “really simple” cases work before you attempt to write any other C++ code.

========

Have fun.

it might be easer to write your C++ code in C …  this is pretty common.

-Duane.