Mirror of the gdb mailing list
 help / color / mirror / Atom feed
* Taking the address of a convenience variable value
@ 2004-05-25 16:55 Paul Dubuc
  2004-05-26  0:00 ` Bob Rossi
  0 siblings, 1 reply; 5+ messages in thread
From: Paul Dubuc @ 2004-05-25 16:55 UTC (permalink / raw)
  To: GDB Mailing List

In the June 2004 issue of the C/C++ User's Journal (p. 24) there is an article 
on how to write user-defined commands for gdb to examine the contents of STL 
vectors, sets and maps.  It looks extremely useful, so I decided to try it 
modifying the commands for use with the GCC STL, but I can't get some of the 
commands for sets and maps to work.  It relies on a tecnique that involves being 
able to take the address of a convenience variable value, for example:

   set $maptype = &$arg0._M_t._M_header->_M_value_field
   set $maptypep = &$maptype

When I try this the 2nd statement gives me the error message

   Attempt to take address of value not located in memory.

It doesn't work with gdb 5.3 or 6.1 on Solaris.  The author claims that it works 
on HP-UX, but I don't know why it would be any different.

Is there a way around this?  Or is there another source of user-defined commands 
that can be used to print the contents of STL containers in gdb?  Any help would 
be very much appreciated.

Thanks,
Paul Dubuc


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Taking the address of a convenience variable value
  2004-05-25 16:55 Taking the address of a convenience variable value Paul Dubuc
@ 2004-05-26  0:00 ` Bob Rossi
  2004-05-26 17:24   ` Andrew Cagney
  0 siblings, 1 reply; 5+ messages in thread
From: Bob Rossi @ 2004-05-26  0:00 UTC (permalink / raw)
  To: Paul Dubuc; +Cc: GDB Mailing List

On Tue, May 25, 2004 at 12:55:46PM -0400, Paul Dubuc wrote:
> In the June 2004 issue of the C/C++ User's Journal (p. 24) there is an 
> article on how to write user-defined commands for gdb to examine the 
> contents of STL vectors, sets and maps.  It looks extremely useful, so I 
> decided to try it modifying the commands for use with the GCC STL, but I 
> can't get some of the commands for sets and maps to work.  It relies on a 
> tecnique that involves being able to take the address of a convenience 
> variable value, for example:
> 
>   set $maptype = &$arg0._M_t._M_header->_M_value_field
>   set $maptypep = &$maptype
> 
> When I try this the 2nd statement gives me the error message
> 
>   Attempt to take address of value not located in memory.
> 
> It doesn't work with gdb 5.3 or 6.1 on Solaris.  The author claims that it 
> works on HP-UX, but I don't know why it would be any different.
> 
> Is there a way around this?  Or is there another source of user-defined 
> commands that can be used to print the contents of STL containers in gdb?  
> Any help would be very much appreciated.

I read that article and was wondering if it was necessary to compile the
STL with -g and not with -O2. I don't think the author mentioned it, but
how else could all of the symbols in the STL work properly with GDB?

Bob Rossi


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Taking the address of a convenience variable value
  2004-05-26  0:00 ` Bob Rossi
@ 2004-05-26 17:24   ` Andrew Cagney
  2004-05-26 17:31     ` Daniel Jacobowitz
  0 siblings, 1 reply; 5+ messages in thread
From: Andrew Cagney @ 2004-05-26 17:24 UTC (permalink / raw)
  To: Bob Rossi, Paul Dubuc; +Cc: GDB Mailing List

> On Tue, May 25, 2004 at 12:55:46PM -0400, Paul Dubuc wrote:
> 
>>> In the June 2004 issue of the C/C++ User's Journal (p. 24) there is an 
>>> article on how to write user-defined commands for gdb to examine the 
>>> contents of STL vectors, sets and maps.  It looks extremely useful, so I 
>>> decided to try it modifying the commands for use with the GCC STL, but I 
>>> can't get some of the commands for sets and maps to work.  It relies on a 
>>> tecnique that involves being able to take the address of a convenience 
>>> variable value, for example:
>>> 
>>>   set $maptype = &$arg0._M_t._M_header->_M_value_field
>>>   set $maptypep = &$maptype
>>> 
>>> When I try this the 2nd statement gives me the error message
>>> 
>>>   Attempt to take address of value not located in memory.

As you note, its trying to take the address of a convenience variable - 
since convenience variables do not live in the inferior they don't have 
an address.

Does:

  set $maptype = &$arg0._M_t._M_header->_M_value_field
  set $maptypep = &&$arg0._M_t._M_header->_M_value_field

or:

  set $maptype = $arg0._M_t._M_header->_M_value_field
  set $maptypep = &$arg0._M_t._M_header->_M_value_field

make sense?

The other, sigh, possability is that this was a ``feature'' and there's 
been a regression :-/

Andrew



>>> It doesn't work with gdb 5.3 or 6.1 on Solaris.  The author claims that it 
>>> works on HP-UX, but I don't know why it would be any different.
>>> 
>>> Is there a way around this?  Or is there another source of user-defined 
>>> commands that can be used to print the contents of STL containers in gdb?  
>>> Any help would be very much appreciated.
> 
> 
> I read that article and was wondering if it was necessary to compile the
> STL with -g and not with -O2. I don't think the author mentioned it, but
> how else could all of the symbols in the STL work properly with GDB?

What does:

   (gdb) paddr &$arg0._M_t._M_header->_M_value_field

display?


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Taking the address of a convenience variable value
  2004-05-26 17:24   ` Andrew Cagney
@ 2004-05-26 17:31     ` Daniel Jacobowitz
  2004-05-26 18:11       ` Paul Dubuc
  0 siblings, 1 reply; 5+ messages in thread
From: Daniel Jacobowitz @ 2004-05-26 17:31 UTC (permalink / raw)
  To: Andrew Cagney; +Cc: Bob Rossi, Paul Dubuc, GDB Mailing List

On Wed, May 26, 2004 at 01:24:34PM -0400, Andrew Cagney wrote:
> >On Tue, May 25, 2004 at 12:55:46PM -0400, Paul Dubuc wrote:
> >
> >>>In the June 2004 issue of the C/C++ User's Journal (p. 24) there is an 
> >>>article on how to write user-defined commands for gdb to examine the 
> >>>contents of STL vectors, sets and maps.  It looks extremely useful, so I 
> >>>decided to try it modifying the commands for use with the GCC STL, but I 
> >>>can't get some of the commands for sets and maps to work.  It relies on 
> >>>a tecnique that involves being able to take the address of a convenience 
> >>>variable value, for example:
> >>>
> >>>  set $maptype = &$arg0._M_t._M_header->_M_value_field
> >>>  set $maptypep = &$maptype
> >>>
> >>>When I try this the 2nd statement gives me the error message
> >>>
> >>>  Attempt to take address of value not located in memory.
> 
> As you note, its trying to take the address of a convenience variable - 
> since convenience variables do not live in the inferior they don't have 
> an address.
> 
> Does:
> 
>  set $maptype = &$arg0._M_t._M_header->_M_value_field
>  set $maptypep = &&$arg0._M_t._M_header->_M_value_field
> 
> or:
> 
>  set $maptype = $arg0._M_t._M_header->_M_value_field
>  set $maptypep = &$arg0._M_t._M_header->_M_value_field
> 
> make sense?
> 
> The other, sigh, possability is that this was a ``feature'' and there's 
> been a regression :-/

Or that it never worked in the FSF tree at all.  There's a reference
below to HP-UX - could this be HP's hacked GDB sources?

> What does:
> 
>   (gdb) paddr &$arg0._M_t._M_header->_M_value_field
> 
> display?

I don't think GDB has a paddr command?

-- 
Daniel Jacobowitz


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Taking the address of a convenience variable value
  2004-05-26 17:31     ` Daniel Jacobowitz
@ 2004-05-26 18:11       ` Paul Dubuc
  0 siblings, 0 replies; 5+ messages in thread
From: Paul Dubuc @ 2004-05-26 18:11 UTC (permalink / raw)
  To: Daniel Jacobowitz; +Cc: Andrew Cagney, Bob Rossi, GDB Mailing List



Daniel Jacobowitz wrote:
> On Wed, May 26, 2004 at 01:24:34PM -0400, Andrew Cagney wrote:
> 
>>>On Tue, May 25, 2004 at 12:55:46PM -0400, Paul Dubuc wrote:
>>>
>>>
>>>>>In the June 2004 issue of the C/C++ User's Journal (p. 24) there is an 
>>>>>article on how to write user-defined commands for gdb to examine the 
>>>>>contents of STL vectors, sets and maps.  It looks extremely useful, so I 
>>>>>decided to try it modifying the commands for use with the GCC STL, but I 
>>>>>can't get some of the commands for sets and maps to work.  It relies on 
>>>>>a tecnique that involves being able to take the address of a convenience 
>>>>>variable value, for example:
>>>>>
>>>>> set $maptype = &$arg0._M_t._M_header->_M_value_field
>>>>> set $maptypep = &$maptype
>>>>>
>>>>>When I try this the 2nd statement gives me the error message
>>>>>
>>>>> Attempt to take address of value not located in memory.
>>>>
>>As you note, its trying to take the address of a convenience variable - 
>>since convenience variables do not live in the inferior they don't have 
>>an address.
>>
>>Does:
>>
>> set $maptype = &$arg0._M_t._M_header->_M_value_field
>> set $maptypep = &&$arg0._M_t._M_header->_M_value_field
>>
>>or:
>>
>> set $maptype = $arg0._M_t._M_header->_M_value_field
>> set $maptypep = &$arg0._M_t._M_header->_M_value_field
>>
>>make sense?
>>
>>The other, sigh, possability is that this was a ``feature'' and there's 
>>been a regression :-/
> 
> 
> Or that it never worked in the FSF tree at all.  There's a reference
> below to HP-UX - could this be HP's hacked GDB sources?
> 
> 
>>What does:
>>
>>  (gdb) paddr &$arg0._M_t._M_header->_M_value_field
>>
>>display?
> 
> 
> I don't think GDB has a paddr command?
> 

Herman Pijl, the author of the article, passed this on to me from someone who 
e-mailed him about the same problem.  This works:

set $maptype = &$arg0._M_t._M_header->_M_value_field
set $maptypep = {&$arg0._M_t._M_header->_M_value_field}

I don't know why.

-- 
Paul M. Dubuc


^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2004-05-26 18:11 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-05-25 16:55 Taking the address of a convenience variable value Paul Dubuc
2004-05-26  0:00 ` Bob Rossi
2004-05-26 17:24   ` Andrew Cagney
2004-05-26 17:31     ` Daniel Jacobowitz
2004-05-26 18:11       ` Paul Dubuc

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox