This is an archive of the discontinued LLVM Phabricator instance.

[lldb] Fix TestDeletedExecutable on linux
ClosedPublic

Authored by labath on Aug 2 2022, 5:05 AM.

Details

Summary

Currently, lldb-server was opening the executable file to determine the
process architecture (to differentiate between 32 and 64 bit
architecture flavours). This isn't a particularly trustworthy source of
information (the file could have been changed since the process was
started) and it is not always available (file could be deleted or
otherwise inaccessible).

Unfortunately, ptrace does not give us a direct API to access the
process architecture, but we can still infer it via some of its
responses -- given that the general purpose register set of 64-bit
applications is larger [citation needed] than the GPR set of 32-bit
ones, we can just ask for the application GPR set and check its size.

This is what this patch does.

Diff Detail

Event Timeline

labath created this revision.Aug 2 2022, 5:05 AM
Herald added a project: Restricted Project. · View Herald TranscriptAug 2 2022, 5:05 AM
labath requested review of this revision.Aug 2 2022, 5:05 AM
Herald added a project: Restricted Project. · View Herald TranscriptAug 2 2022, 5:05 AM

Tell me if I understand the strategy.

If you're on arm64 but the process is actually arm32 and you ask for the general registers, you'll get back something with size < the size you expect for the 64 bit register set.
If you're on arm32 then you always assume that the architecture is the host architecture (since there's no backward compatibility mode to worry about).
(though see my comment about potential cross arch shenanigans)

Ditto for x86_64 and i386.

If the architecture doesn't have a 32/64 split then assume host architecture (as you did for s390x).

And ppc64 we don't support a ppc32 so again use the host (and maybe ppc64 doesn't have a backward compatibility mode in linux anyway).

And you're looking at the size of the register context, not the number of registers or their names or whatever. So even for something like RISCV vs RISCV64 where the number and names of registers is the same, the *size* changes with the bitness (xlen I think they call it) so it would still work.

If so, sounds good to me.

lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux.cpp
162

Rename this gpr64s_size something like that. It took me a bit to realise that it wasn't the value of a register, or meant to be a return by ref of the result somehow.

lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm.cpp
844

Is this a problem? First time I'm seeing such code I thought to debug arm32 on arm64 you just had to use an arm32 lldb-server binary.

Host architecture would be arm64 if __aarch64__ was defined, right? Same thing if I took an arm32 lldb-server binary and ran it on arm64, host is arm64.

Or is this not a problem. This architecture detection is a last resort so not getting a corner case right might be fine.

labath marked an inline comment as done.Aug 2 2022, 6:42 AM

Tell me if I understand the strategy.

If you're on arm64 but the process is actually arm32 and you ask for the general registers, you'll get back something with size < the size you expect for the 64 bit register set.
If you're on arm32 then you always assume that the architecture is the host architecture (since there's no backward compatibility mode to worry about).
(though see my comment about potential cross arch shenanigans)

Ditto for x86_64 and i386.

If the architecture doesn't have a 32/64 split then assume host architecture (as you did for s390x).

And ppc64 we don't support a ppc32 so again use the host (and maybe ppc64 doesn't have a backward compatibility mode in linux anyway).

And you're looking at the size of the register context, not the number of registers or their names or whatever. So even for something like RISCV vs RISCV64 where the number and names of registers is the same, the *size* changes with the bitness (xlen I think they call it) so it would still work.

That is correct. I couldn't have said it better myself. :)

If so, sounds good to me.

lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm.cpp
792

This one.

844

Well.. it's definitely not a problem here. I think this is related to the problem on described on line 792 (they were introduced in the same commit -- e85e6021f040e399203883a78c53b1617053e141), although it may not be relevant anymore.

Generally speaking there can be some differences in the 32-bit codepaths when speaking to 32 or 64-bit kernels. For example, one can use PTRACE_SINGLESTEP for debugging arm(32) binaries on 64-bit kernels, even though that functionality would is not present on real 32-bit kernels.

labath updated this revision to Diff 449282.Aug 2 2022, 6:42 AM

rename the size variable

This revision is now accepted and ready to land.Aug 2 2022, 7:27 AM
This revision was automatically updated to reflect the committed changes.
labath added a comment.Aug 4 2022, 4:32 AM

I see it. Looking now.