If user attaches to a local process by pid without executable assigned to a target we can deduce an executable path by pid, otherwise no symbols are loaded and not possible to set up breakpoints.
Details
Diff Detail
Event Timeline
Doesn't the auxv data say what the executable is, or does it only contain the shared libraries? If it contains the executable you should check if the executable matches the executable in the target. If it doesn't you will need to get the process info and always update the executable if needed. Examples to show how this can happen are below:
You might want to check if the executable is correct or not regardless of what it is set to. Try this:
In one terminal:
% /bin/cat
And leave it there so it is waiting for stdin
Then in another terminal do:
(lldb) file /bin/ls
(lldb) process attach --pid 123
Where 123 is the process ID for /bin/cat. You should switch the executable if it isn't correct.
Also, try making a program "a.out" that exec()'s itself into something else like "b.out" and make sure the executable updates when the process exec's into another executable and can hit a breakpoint that you set in "a.out" and "b.out" (like setting a breakpoint at "main" with "(lldb) b main".
The job of the dynamic loader is to keep the target up to date and make sure the executable is always correct. You can't rely on what the target contains. The architecture also needs to be updated sometimes in case you do:
(lldb) target create --arch i386 a.out
And then you attach to a b.out that is "x86_64"...
Thank you for suggestions - I've made corresponding changes to handle such situations when a module file name and/or architecture changes.
Initially I tried to use AT_EXECFN but as I can see it's not reliable option - for example, when I start application from its binary directory (e.g., ./CppTest) AT_EXECFN will be set to "./CppTest" instead of providing a full path.