What is argdumper?

I’ve been going through the backlog of “reasons the windows bot is red this morning”, and the current issue I’m on is related to argdumper. I understand the problem, which is that the sequence of events the build system is taking is:

  1. Build liblldb
  2. Create lldb python symlink
  3. Create argdumper symlink
  4. Build argdumper

And #3 is a hardlink on Windows since creating a symlink is unsupported by python.

So I can fix this, but at the same time I’d like to understand what argdumper is and why we need a symlink to it in lib/site-packages/lldb?

A common problem on Unix is somebody has a command line program they want to debug, in some scenario where it gets run with a bunch of arguments that include some shell expansions. e.g.:

$ my_program *.c

To debug it correctly they want to run it through their shell to get the arguments expanded correctly. Traditionally the debugger handled this by something like:

/bin/sh -c 'exec my_program *.c'

This requires the debugger to follow through a bunch of exec's till it arrives at the one which is the process it actually wants to debug. That process is annoying and error prone, and gets even more so when you want to specify the architecture of the binary you want to run. Add to that the fact that on OS X you also have to track not just the PID of the process but the Mach Task port, which may or may not change as these exec's continue along, and it starts crying out for a simpler way...

Our version of that way is to have a little program - argdumper - whose job is to take its arguments and return them in some structured form (JSON in this case.) So then we can just launch argdumper with the specified arguments, read the expanded version from argdumper's output, then use them to launch the program we want to run directly.

I don't know if you've hooked up "start-with-shell" on Windows. But anyway, if you want to do such a thing, then this might be an easier way for you to do it as well.

Jim

To debug it correctly they want to run it through their shell to get the arguments expanded correctly. Traditionally the debugger handled this by something like:

Should have said "Traditionally the debugger handled this by instead debugging a command of the form:"

/bin/sh -c 'exec my_program *.c'

Jim

Is this being used from python? I’m wondering why there needs to be a symlink that is in the same folder as the python extension module.

So as far as I know argdumper should only need to be somewhere lldb can find it, i.e. wherever debugserver & lldb_platform lives. I don't know why there would need to be a symlink of it anywhere. Enrico says he doesn't know either.

Jim

Thanks! That’s helpful. Sounds like we probably don’t need it then.

Is this being used from python? I’m wondering why there needs to be a symlink that is in the same folder as the python extension module.

In the Xcode build, argdumper gets copied to LLDB.framework/Contents/Resources/ - which is the same place where debugserver and any other LLDB’s own helper tools would also get copied
As for where it ends up being copied (or symlinked or hard linked depending on your platform) on non-Mac non-Xcode builds, that entirely depends on whoever touched that build process

As a general matter, LLDB expects to have argdumper be a resource it can locate relative to itself just like debugserver