This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC - Python scripting] New methods Symtab.global_block and Symtab.static_block (docs included)


On Fri, Apr 20, 2012 at 4:43 AM, Matt Rice <ratmice@gmail.com> wrote:
> ? ? ?/* This shouldn't be necessary, but as a last resort
> ? ? ? * try looking in the 'other kind' even though the psymtab
> ? ? ? * claimed the symbol was one thing. ?It's possible that
> ? ? ? * the psymtab gets it wrong in some cases.
> ? ? ? */
> ? ? ?block = BLOCKVECTOR_BLOCK (bv, other_kind);
> ? ? ?sym = lookup_block_symbol (block, name, STRUCT_DOMAIN);
>
> ....
>
> ? ? ?/* This shouldn't be necessary, but as a last resort try
> ? ? ? ? looking in the statics even though the psymtab claimed
> ? ? ? ? the symbol was global, or vice-versa. ?It's possible
> ? ? ? ? that the psymtab gets it wrong in some cases. ?*/
>
> ? ? ?/* FIXME: carlton/2002-09-30: Should we really do that?
> ? ? ? ? If that happens, isn't it likely to be a GDB error, in
> ? ? ? ? which case we should fix the GDB error rather than
> ? ? ? ? silently dealing with it here? ?So I'd vote for
> ? ? ? ? removing the check for the symbol in the other
> ? ? ? ? block. ?*/
> ? ? ?block = BLOCKVECTOR_BLOCK (bv,
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? kind == GLOBAL_BLOCK ?
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? STATIC_BLOCK : GLOBAL_BLOCK);

That reminds me, thanks!
[Assuming I'm remembering correctly, can be dangerous at times :-)]
The cost of this can be, umm, quite depressing.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]