language switching

[Martin v.Loewis]

In article <9634c9$p2m$1 at nnrp1.deja.com>,  <etoffi at bigfoot.com> wrote:
>what would be needed to debug code going across two languages, such as
>python and eiffel, maybe with a little c in between (ie for gtk), maybe
>over corba or xmlrpc?

If the language runtimes all live in a single process, you need the 
debugger to tell what the language of the current function is. For example,
gdb supports multi-language debugging and will autodetect the language based
on the debug information.

>is there a debugger that understands corba?
>how about xmlrpc on a local machine?

In either case, the debugger would need to find out the process that runs
the service/object implementation, and attach to that process - which may
be difficult if the process is on a different machine. I'm not aware of
a debugger that does that for either CORBA or xmlrpc; I think MSVC supports
tracing COM calls over process boundaries.

>how complicated would either (or both) of these be?

You'd teach the debugger about the specifics of the runtime for the RPC
mechanism, e.g. how the language mapping works, how the IORs are represented
in memory, how to find out what sockets are used. With that, the debugger
could attach to the other end of the connection and trace the incoming call.

>and without the rpc/ipc stuff, how difficult would that be?
>i figure alot simpler than the other two...

Depends on the debugger, and the language. For gdb, telling it about another
"compiled" language is primarily a matter of defining debug information.
If the debugger already supports debugging that language, mixed-language
debugging should work out of the box.

In order to debug interpreted languages, you'd need to tell the debugger
details about the interpreter. E.g. for Python, you'd need to tell it
about the SET_LINENO instruction so it can do single-stepping, and you'd
need to inform it about the FrameObject and ThreadState so it can find
out what the local and global variables are.

Regards,
Martin