This is the mail archive of the gdb-prs@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]

[Bug python/12656] gdb.Block should expose whether the block isspecial


http://sourceware.org/bugzilla/show_bug.cgi?id=12656

Jan Kratochvil <jan.kratochvil at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jan.kratochvil at redhat
                   |                            |dot com

--- Comment #1 from Jan Kratochvil <jan.kratochvil at redhat dot com> 2011-04-12 21:15:25 UTC ---
Notes for Phil Muldoon which are more general and may not be specific for this
Bug:

http://sourceware.org/ml/gdb-patches/2011-04/msg00143.html
# There is still gdbpy_block_for_pc (unaffected by this patch at all) which
# works as described but it may be confusing as it does not behave well with
# inlined functions when used as is.

I do not see block_for_pc to be used in the .py scripts shipped in GDB but any
such use should be reviewed wrt inlined functions correctness.

One should always derive block from its frame by get_frame_block.  Relying on
any PC there may produce incorrect results.  Which should be already done fine
by frapy_block.

frapy_block should never need to return GLOBAL_BLOC or STATIC_BLOCK so there
should not be a problem the current code does not allow it.

Maybe everything is correct and nothing needs to be changed now, thanks.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.


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