* Using C++ code inside gdb @ 2015-10-08 10:57 Ashutosh 2015-10-08 13:05 ` Aw: " Klaus Rudolph 0 siblings, 1 reply; 11+ messages in thread From: Ashutosh @ 2015-10-08 10:57 UTC (permalink / raw) To: gdb Hi All, I plan to add a standalone module inside gdb code that contains information about the memories in the target, but want to organize it in the form of a C++ class. My question is: Has anybody earlier tried adding C++ code to gdb code-base and how easy it would be to do so? Any guidelines? Thanks, ash ^ permalink raw reply [flat|nested] 11+ messages in thread
* Aw: Using C++ code inside gdb 2015-10-08 10:57 Using C++ code inside gdb Ashutosh @ 2015-10-08 13:05 ` Klaus Rudolph 2015-10-09 3:20 ` Ashutosh 0 siblings, 1 reply; 11+ messages in thread From: Klaus Rudolph @ 2015-10-08 13:05 UTC (permalink / raw) To: Ashutosh; +Cc: gdb > > I plan to add a standalone module inside gdb code that contains > information about the memories in the target, but want to organize it > in the form of a C++ class. My question is: Has anybody earlier tried > adding C++ code to gdb code-base and how easy it would be to do so? > Any guidelines? > You can call every function/method with "print funcName" from gdb command line. So if you add your debug code to your executable you should be able to run every function from your debug extension. You must take care that your debug code is not optimized out because you have no calls from your application to the debug code itself. So you do not need any changes to the debugger or gdbserver itself. But maybe I have a misunderstanding from your question... Regards Klaus ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Using C++ code inside gdb 2015-10-08 13:05 ` Aw: " Klaus Rudolph @ 2015-10-09 3:20 ` Ashutosh 2015-10-09 4:29 ` Duane Ellis 0 siblings, 1 reply; 11+ messages in thread From: Ashutosh @ 2015-10-09 3:20 UTC (permalink / raw) To: Klaus Rudolph; +Cc: gdb 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. The solution that you propose doesn't fit the scenario I am shooting for, as I want the module functions to be called from with-in gdb and not from the command-line interface. Sorry for not clarifying the context earlier. Thanks and Regards, ash On Thu, Oct 8, 2015 at 6:35 PM, Klaus Rudolph <lts-rudolph@gmx.de> wrote: > >> >> I plan to add a standalone module inside gdb code that contains >> information about the memories in the target, but want to organize it >> in the form of a C++ class. My question is: Has anybody earlier tried >> adding C++ code to gdb code-base and how easy it would be to do so? >> Any guidelines? >> > > You can call every function/method with "print funcName" from gdb command line. So if you add your debug code to your executable you should be able > to run every function from your debug extension. You must take care that your debug code is not optimized out because > you have no calls from your application to the debug code itself. So you do not need any changes to the debugger or gdbserver > itself. > > But maybe I have a misunderstanding from your question... > > Regards > Klaus ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Using C++ code inside gdb 2015-10-09 3:20 ` Ashutosh @ 2015-10-09 4:29 ` Duane Ellis 2015-10-09 6:08 ` Ashutosh 0 siblings, 1 reply; 11+ messages in thread From: Duane Ellis @ 2015-10-09 4:29 UTC (permalink / raw) To: Ashutosh; +Cc: Klaus Rudolph, gdb > 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. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Using C++ code inside gdb 2015-10-09 4:29 ` Duane Ellis @ 2015-10-09 6:08 ` Ashutosh 2015-10-09 9:41 ` Pedro Alves 0 siblings, 1 reply; 11+ messages in thread From: Ashutosh @ 2015-10-09 6:08 UTC (permalink / raw) To: Duane Ellis; +Cc: Klaus Rudolph, gdb Hi Duane, I am actually interfacing gdb with a specific target (agent-less) and not going the RSP way. But still, thanks for the pointer; I will see if I can make use of it. Regarding using C++, I just hit upon the following conversation on the gdb-patches list: https://sourceware.org/ml/gdb-patches/2015-02/msg00202.html where it seems that there's some work going on compiling gdb sources with g++. Any idea if this support is available in some form already in gdb 7.10 or when is it planned to be released? Thanks and Regards, ash On Fri, Oct 9, 2015 at 9:59 AM, Duane Ellis <duane@duaneellis.com> wrote: > >> 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. > > > > ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Using C++ code inside gdb 2015-10-09 6:08 ` Ashutosh @ 2015-10-09 9:41 ` Pedro Alves 2015-10-09 10:00 ` vijay nag 2015-10-10 21:32 ` Mike Frysinger 0 siblings, 2 replies; 11+ messages in thread From: Pedro Alves @ 2015-10-09 9:41 UTC (permalink / raw) To: Ashutosh, Duane Ellis; +Cc: Klaus Rudolph, gdb Hello, On 10/09/2015 07:08 AM, Ashutosh wrote: > Regarding using C++, I just hit upon the following conversation on the > gdb-patches list: > https://sourceware.org/ml/gdb-patches/2015-02/msg00202.html > > where it seems that there's some work going on compiling gdb sources > with g++. Any idea if this support is available in some form already > in gdb 7.10 or when is it planned to be released? The status in the wiki page linked from that url is accurate. GDB nowadays builds and links in C++ when configured with --enable-build-with-cxx, though that still spews a ton of warnings. There's been constant incremental progress so we'll get there eventually. No release has been marked as the one where we'll switch to C++ as default language -- it'll get done when it's done; though the sooner the better. :-) Thanks, Pedro Alves ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Using C++ code inside gdb 2015-10-09 9:41 ` Pedro Alves @ 2015-10-09 10:00 ` vijay nag 2015-10-09 10:06 ` Pedro Alves 2015-10-10 21:32 ` Mike Frysinger 1 sibling, 1 reply; 11+ messages in thread From: vijay nag @ 2015-10-09 10:00 UTC (permalink / raw) To: Pedro Alves; +Cc: Ashutosh, Duane Ellis, Klaus Rudolph, gdb On Fri, Oct 9, 2015 at 3:11 PM, Pedro Alves <palves@redhat.com> wrote: > Hello, > > On 10/09/2015 07:08 AM, Ashutosh wrote: > >> Regarding using C++, I just hit upon the following conversation on the >> gdb-patches list: >> https://sourceware.org/ml/gdb-patches/2015-02/msg00202.html >> >> where it seems that there's some work going on compiling gdb sources >> with g++. Any idea if this support is available in some form already >> in gdb 7.10 or when is it planned to be released? > > The status in the wiki page linked from that url is accurate. > > GDB nowadays builds and links in C++ when configured > with --enable-build-with-cxx, though that still spews a ton of warnings. > There's been constant incremental progress so we'll get there eventually. > > No release has been marked as the one where we'll switch to C++ as > default language -- it'll get done when it's done; though the sooner > the better. :-) > > Thanks, > Pedro Alves > Is there an open ticket for the same ? Thanks, Vijay Nag ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Using C++ code inside gdb 2015-10-09 10:00 ` vijay nag @ 2015-10-09 10:06 ` Pedro Alves 0 siblings, 0 replies; 11+ messages in thread From: Pedro Alves @ 2015-10-09 10:06 UTC (permalink / raw) To: vijay nag; +Cc: Ashutosh, Duane Ellis, Klaus Rudolph, gdb On 10/09/2015 11:00 AM, vijay nag wrote: > Is there an open ticket for the same ? There wasn't, but I've opened one now: https://sourceware.org/bugzilla/show_bug.cgi?id=19105 Thanks, Pedro Alves ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Using C++ code inside gdb 2015-10-09 9:41 ` Pedro Alves 2015-10-09 10:00 ` vijay nag @ 2015-10-10 21:32 ` Mike Frysinger 2015-10-11 8:57 ` Mike Frysinger 1 sibling, 1 reply; 11+ messages in thread From: Mike Frysinger @ 2015-10-10 21:32 UTC (permalink / raw) To: Pedro Alves; +Cc: Ashutosh, Duane Ellis, Klaus Rudolph, gdb [-- Attachment #1: Type: text/plain, Size: 1383 bytes --] On 09 Oct 2015 10:41, Pedro Alves wrote: > On 10/09/2015 07:08 AM, Ashutosh wrote: > > Regarding using C++, I just hit upon the following conversation on the > > gdb-patches list: > > https://sourceware.org/ml/gdb-patches/2015-02/msg00202.html > > > > where it seems that there's some work going on compiling gdb sources > > with g++. Any idea if this support is available in some form already > > in gdb 7.10 or when is it planned to be released? > > The status in the wiki page linked from that url is accurate. > > GDB nowadays builds and links in C++ when configured > with --enable-build-with-cxx, though that still spews a ton of warnings. > There's been constant incremental progress so we'll get there eventually. > > No release has been marked as the one where we'll switch to C++ as > default language -- it'll get done when it's done; though the sooner > the better. :-) even if the C++ frontend is used, and C++ is the default language, that doesn't mean that all C++ functionality will be accepted. there are a lot of design patterns and C++ APIs that are generally bad, and gdb is meant to be portable. so i'd expect there will be guidelines put together as to acceptable standards base (C11/C14/etc...) as well as headers and interfaces that are permitted and ones that are banned. saying "it's C++ now!" is pretty vague ;). -mike [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Using C++ code inside gdb 2015-10-10 21:32 ` Mike Frysinger @ 2015-10-11 8:57 ` Mike Frysinger 2015-10-11 14:23 ` Joel Brobecker 0 siblings, 1 reply; 11+ messages in thread From: Mike Frysinger @ 2015-10-11 8:57 UTC (permalink / raw) To: Pedro Alves, Ashutosh, Duane Ellis, Klaus Rudolph, gdb [-- Attachment #1: Type: text/plain, Size: 1594 bytes --] On 10 Oct 2015 17:32, Mike Frysinger wrote: > On 09 Oct 2015 10:41, Pedro Alves wrote: > > On 10/09/2015 07:08 AM, Ashutosh wrote: > > > Regarding using C++, I just hit upon the following conversation on the > > > gdb-patches list: > > > https://sourceware.org/ml/gdb-patches/2015-02/msg00202.html > > > > > > where it seems that there's some work going on compiling gdb sources > > > with g++. Any idea if this support is available in some form already > > > in gdb 7.10 or when is it planned to be released? > > > > The status in the wiki page linked from that url is accurate. > > > > GDB nowadays builds and links in C++ when configured > > with --enable-build-with-cxx, though that still spews a ton of warnings. > > There's been constant incremental progress so we'll get there eventually. > > > > No release has been marked as the one where we'll switch to C++ as > > default language -- it'll get done when it's done; though the sooner > > the better. :-) > > even if the C++ frontend is used, and C++ is the default language, that doesn't > mean that all C++ functionality will be accepted. there are a lot of design > patterns and C++ APIs that are generally bad, and gdb is meant to be portable. > so i'd expect there will be guidelines put together as to acceptable standards > base (C11/C14/etc...) as well as headers and interfaces that are permitted and > ones that are banned. seems like gcc has already done this: https://gcc.gnu.org/codingconventions.html probably be best to try and follow that, or at least use it as a base. -mike [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Using C++ code inside gdb 2015-10-11 8:57 ` Mike Frysinger @ 2015-10-11 14:23 ` Joel Brobecker 0 siblings, 0 replies; 11+ messages in thread From: Joel Brobecker @ 2015-10-11 14:23 UTC (permalink / raw) To: Pedro Alves, Ashutosh, Duane Ellis, Klaus Rudolph, gdb > seems like gcc has already done this: > https://gcc.gnu.org/codingconventions.html > > probably be best to try and follow that, or at least use it as a base. That's what was already proposed. See: https://sourceware.org/gdb/wiki/cxx-conversion -- Joel ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2015-10-11 14:23 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-10-08 10:57 Using C++ code inside gdb Ashutosh 2015-10-08 13:05 ` Aw: " Klaus Rudolph 2015-10-09 3:20 ` Ashutosh 2015-10-09 4:29 ` Duane Ellis 2015-10-09 6:08 ` Ashutosh 2015-10-09 9:41 ` Pedro Alves 2015-10-09 10:00 ` vijay nag 2015-10-09 10:06 ` Pedro Alves 2015-10-10 21:32 ` Mike Frysinger 2015-10-11 8:57 ` Mike Frysinger 2015-10-11 14:23 ` Joel Brobecker
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).