Risks with extending the python methodpool

[Richard Purdie <richard.purdie@linuxfoundation.org>]

I started today looking at a backtrace problem where the
filename/lineno entries were works of fiction.

That turned out to be "simple" in that exec_func_python() uses FILE as
the filename which may or may not be the case and is basically wrong.
We can at least fix that not to confuse as much.

I realised that only a certain percentage of our functions are making
it into the methodpool, "def x():" ones do, as does anonymous python
and the ones executed by exec_func_python don't.

This causes some problems since the code fragment that exec_func_python
builds can never really have correct filename/linenos as the code
stands today. I therefore started down the path of "why don't we just
put all functions into methodpool".

This would have some advantages, not least that all the methods would
start to become available from things like devshell.

I had this mostly working, or so I thought, then tried a clean build.
glibc blew up. It does:

do_patch_append() {
    bb.build.exec_func('do_fix_readlib_c', d)
}

and do_fix_readlib_c was no longer being executed.

This is because we'd injected an entry for do_patch into methodpool
(from the export_functions code) before the append was known about.

I guess we've never really supported appending to a def x(): style
python function, or to an anonymous python fragment (it has no name) so
there isn't a current issue but we can't extend the methodpool approach
any further :(.

With this all in mind I can go back to the drawing board on how to fix
the original backtrace problem. It does highlight the need to fix
things in a few areas and some good cleanups that can be made. I
thought I'd better write it down as I'll never remember this in six
months though and I thought some others may find it interesting.

Cheers,

Richard