[PATCH 0/6] framefilter quit: PR cli/17716
Pedro Alves
palves@redhat.com
Tue Feb 10 17:40:00 GMT 2015
Hi Jan,
I read this, and it looks pretty good to me.
Phil, any comments?
Thanks,
Pedro Alves
On 02/07/2015 02:45 PM, Jan Kratochvil wrote:
> Hi Phil,
>
> as I have seen gdb-7.9 may get released with this annoying bug I have attempted
> a fix. It is far from complete but it should hopefully handle most of the
> uninterruptable cases - although some of them will apparently still remain
> there.
>
> Primarily I do not understand intentions of the code:
>
> gdbpy_convert_exception() is required in code called from Python, such as for
> bpfinishpy_init() as one of many examples. But if I haven't make mistake I do
> not see any of the GDB functions changed in this patchset (py_print_single_arg,
> enumerate_locals, py_print_frame) would be called by Python. Therefore I do
> not see why they should call gdbpy_convert_exception() at all (moreover they
> call it so many times). These functions are normally called by GDB and GDB is
> GDB exception safe so GDB exceptions can be safely thrown. Not all of the
> gdb/python/ code was GDB exception safe, this is why I had to change for
> example also gdbpy_apply_frame_filter(). I find more safe to write code as
> exception safe in general. Hopefully I did not forget to make exception safe
> any of the possible callers of the involved functions.
>
> Then I do not understand why there is EXT_LANG_BT_ERROR. GDB has exceptions so
> it does not need error return values. Error return values can be used in cases
> when it is more simple for the code (As current implementation of GDB
> exceptions is needlessly complicated to use) - when callee detects a problem on
> its own. But if caller has to TRY_CATCH exceptions from futher callees and
> convert them into EXT_LANG_BT_ERROR so that its caller can check for
> EXT_LANG_BT_ERROR... Why hasn't the caller just do TRY_CATCH on its own?
> I haven't tried to remove EXT_LANG_BT_ERROR at all myself in this patchset,
> though. That would be larger work.
>
> As I said the patch is not complete but I believe the direction of this patch
> is correct and futher fixes can extend it.
More information about the Gdb-patches
mailing list