Re: Taking the address of a convenience variable value

[Paul Dubuc <pdubuc@cas.org>]

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