In the first B::C debugging article we stepped into the B::C compiler with Od.
We saw that the compiler is missing a method_named sub (aka a package->method call), the most typical problem with the compiler.
In the ="https://blogs.perl.org/users/rurban/2010/01/debugging-bc-the-workaround-part-3…

In the first B::C debugging article we stepped into the B::C compiler with Od.
We saw that the compiler is missing a sub in a seperate package, the most typical
problem with the current compiler. (since 1995)

We have a cool workaround for this, the -u option for "use".
/users/rurban/2010/01/index.html

At the previous entry Debugging B::C, hitting the recursion depth I showed how attack a typical B::C problem, how to use the perl level debugger

However we found no error in the compiler at a first glance.
Inspecting the generated c code we see for the perl code

package dummy;sub meth{print "ok"};package main;dummy->meth

parts of the optree as

listop_list[0].op_p…

The nature of the data driven perl compiler is hitting the perl debuggers recursion limit, even on one-liners.

Consider this bug: [CPAN #53889]

package dummy;sub meth{print "ok"};package main;dummy->meth

=>

ok

The compiler does not detect the meth sub in the dummy package.

  $ perl -MO=C,-DcOACMSGpo,-v,-oa.c -e 'package dummy;
                 sub meth{print "ok"};package main;dummy->meth'
  $ cc_harness a.c
  $ ./a

Can't locate object method…