Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: "Vincent Bénony" <vbenony@nordnet.fr>
To: Daniel Jacobowitz <drow@false.org>
Cc: Nick Roberts <nickrob@snap.net.nz>,  gdb-patches@sourceware.org
Subject: Re: Using STL containers with GDB
Date: Wed, 23 Apr 2008 06:49:00 -0000	[thread overview]
Message-ID: <A780444A-F1C2-4A8A-B94D-A03A44784975@nordnet.fr> (raw)
In-Reply-To: <20080422215146.GA3156@caradoc.them.org>


Le 22 avr. 08 à 23:51, Daniel Jacobowitz a écrit :
>>
>> The Python branch appears to work for executables compiled with Gcc  
>> only.  I'm
>> curious to know if this approach will work for executables built  
>> using other
>> compilers?
>
> Vincent's implementation has the layout of the GNU STL implementation
> hardcoded into it - so even less portable than the Python
> implementation, which uses the field names.

You are right, this patch is very hardcoded. I assume that fields of  
STL containers are always in the same order. I ask GDB the size of  
"void *", and I compute fields offsets using this information to read  
things I need. If you use another compiler, but with GNU STL headers,  
this patch *should* continue to work...

The reason why I do not use fields name is that I had some problems  
with GDB parser: my first approach was to use GDB scripts, but there  
were many problems, like no recursive dump (an std::list into an  
std::vector for example), and I was unable to cast a pointer into a  
type that was a template, I mean GDB parser was able to parse a  
expression like

  (gdb) p (struct Something*) pointer

but not something like

  (gdb) p (std::list<int> *) pointer

  So, you should see my patch as a quick an ugly way of using GDB to  
debug program that use STL container today, but not a patch to be  
included into GDB for future releases.

  My idea was first to consider having GDB call some kind of external  
script in particular situation, and this seems to be the goal of  
Python scripting system, and that's why I feel very enthusiast about  
this project.


  reply	other threads:[~2008-04-23  5:48 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-22 12:29 Vincent Benony
2008-04-22 14:41 ` Daniel Jacobowitz
2008-04-22 14:49   ` Vincent Benony
2008-04-22 17:51     ` Thiago Jung Bauermann
2008-04-22 18:37       ` Vladimir Prus
2008-04-22 22:13 ` Nick Roberts
2008-04-22 22:56   ` Daniel Jacobowitz
2008-04-23  6:49     ` Vincent Bénony [this message]
2008-04-23  8:53       ` Eli Zaretskii
2008-04-23  9:29         ` BENONY Vincent
2008-04-23 10:12       ` Nick Roberts
2008-04-23 12:22         ` Daniel Jacobowitz
2009-05-27 20:27 Using STL Containers With GDB Ken Lauterbach
2009-05-27 21:24 ` Paul Pluzhnikov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=A780444A-F1C2-4A8A-B94D-A03A44784975@nordnet.fr \
    --to=vbenony@nordnet.fr \
    --cc=drow@false.org \
    --cc=gdb-patches@sourceware.org \
    --cc=nickrob@snap.net.nz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox