From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32008 invoked by alias); 23 Apr 2008 05:48:26 -0000 Received: (qmail 32000 invoked by uid 22791); 23 Apr 2008 05:48:26 -0000 X-Spam-Check-By: sourceware.org Received: from smtp3-g19.free.fr (HELO smtp3-g19.free.fr) (212.27.42.29) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 23 Apr 2008 05:48:06 +0000 Received: from smtp3-g19.free.fr (localhost.localdomain [127.0.0.1]) by smtp3-g19.free.fr (Postfix) with ESMTP id 3ABCF17B531; Wed, 23 Apr 2008 07:48:04 +0200 (CEST) Received: from [192.168.0.130] (asc59-1-82-237-39-76.fbx.proxad.net [82.237.39.76]) by smtp3-g19.free.fr (Postfix) with ESMTP id C4F1F17B53D; Wed, 23 Apr 2008 07:48:03 +0200 (CEST) Cc: Nick Roberts , gdb-patches@sourceware.org Message-Id: From: =?ISO-8859-1?Q?Vincent_B=E9nony?= To: Daniel Jacobowitz In-Reply-To: <20080422215146.GA3156@caradoc.them.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v919.2) Subject: Re: Using STL containers with GDB Date: Wed, 23 Apr 2008 06:49:00 -0000 References: <1208857199.6213.15.camel@bsr-desktop> <18446.23053.860176.935315@kahikatea.snap.net.nz> <20080422215146.GA3156@caradoc.them.org> X-Mailer: Apple Mail (2.919.2) X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-04/txt/msg00500.txt.bz2 Le 22 avr. 08 =E0 23:51, Daniel Jacobowitz a =E9crit : >> >> The Python branch appears to work for executables compiled with Gcc=20=20 >> only. I'm >> curious to know if this approach will work for executables built=20=20 >> 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=20=20 STL containers are always in the same order. I ask GDB the size of=20=20 "void *", and I compute fields offsets using this information to read=20=20 things I need. If you use another compiler, but with GNU STL headers,=20=20 this patch *should* continue to work... The reason why I do not use fields name is that I had some problems=20=20 with GDB parser: my first approach was to use GDB scripts, but there=20=20 were many problems, like no recursive dump (an std::list into an=20=20 std::vector for example), and I was unable to cast a pointer into a=20=20 type that was a template, I mean GDB parser was able to parse a=20=20 expression like (gdb) p (struct Something*) pointer but not something like (gdb) p (std::list *) pointer So, you should see my patch as a quick an ugly way of using GDB to=20=20 debug program that use STL container today, but not a patch to be=20=20 included into GDB for future releases. My idea was first to consider having GDB call some kind of external=20=20 script in particular situation, and this seems to be the goal of=20=20 Python scripting system, and that's why I feel very enthusiast about=20=20 this project.