What I've *done* in the past, but I can't remember how pretty that was:
GDB has python integration (essentially, a large gdb script + python debug infos). If you
can break at a C++ function that your python work() calls, you should be able to e.g.
py-bt into the mother frames etc.
Cheers,
Marcus
On 17.01.21 22:52, Jeff Long wrote:
> Yah, there might be some kind of hack, but you're right ... since a Python block is being
> exec'd via a C++-to-Python gateway it's in a no man's land from the debugger perspective.
>
> On Sun, Jan 17, 2021 at 4:46 PM Nicholas Long <nicholaslong94@gmail.com
> <mailto:nicholaslong94@gmail.com>> wrote:
>
> So I get the fact that GNURadio is highly parallel, that is fine. I debug C++ OOT
> blocks all the time and it is super easy, generally I make specific effort to isolate
> the OOT block that I am currently working on in a test flowgraph.
>
> For C++ OOT blocks I just run the python top_block.py in gdb (via vscode), and place a
> breakpoint in my C++ OOT block, and it works.
>
> If I want to debug the python flowgraph, (generated from GRC or custom), I can do that
> via the python debug tool, I cannot step through the internals of blocks, but can see
> if things are hooking up correctly.
>
> my problem, (and I personally don't think that there is a solution, but am happy to be
> wrong) is that there is no way to place a breakpoint inside a python block, like I do
> in the c++ blocks. presumably the swig (I'm still on 3.8) process removes all the
> information?.
>
> As for specific use cases, the more complex blocks I write are all C++, but sometimes
> it is useful to write a quick and dirty python block which I can then use for
> debugging purposes. However when I do this I have to resort to using print statements
> to make sure everything is working like I expect. It's ok and workable, but I am not
> that good of a programmer and tend to do guess and check, which a debugger, rather
> than adding/removing print statements really speeds up.
>
> So I guess there is nothing in particular to debug, but If there is a more efficient
> way to work I would love to know.
>
> Nick
>
> On Sat, Jan 16, 2021 PM Jeff Long wrote:
>
> Python includes a debugger (pdb) and IDEs like VSCode have decent Python
> debugging. This should work fine for Python scripts like those generated by GRC.
> Internally, GNU Radio is highly parallel, which creates additional challenges not
> related to language ... how do you stop one block when that changes the behavior
> of, or crashes, the whole framework?
>
> Anything in particular you are trying to debug?
>
> On Sat, Jan 16, 2021 at 6:51 PM Nicholas Long <nicholaslong94@gmail.com
> <mailto:nicholaslong94@gmail.com>> wrote:
>
> So this is a relatively generic question about what people's processes for
> writing and debugging python blocks are.
>
> In C++ I use VScode and just run the gdb debugger - I can place breakpoints,
> look at variables, and step through the program super easily.
>
> Ideally I would like to be able to do the same with python blocks, but am not
> sure if it is possible.
>
> Thanks,
> Nick
>
No comments:
Post a Comment