Taking the address of a convenience variable value
Paul Dubuc
pdubuc@cas.org
Wed May 26 18:11:00 GMT 2004
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
More information about the Gdb
mailing list