The implementation of GDBRemoteRegisterContext relies on byte offsets to cache
register values. GPR, FPR, etc. should start on different offsets. This is
correctly done in debugserver (in DNBArchImplX86_64.cpp), but not on Linux or
FreeBSD (in RegisterInfos_x86_64.h).
Details
- Reviewers
emaste sivachandra ovyalov clayborg jingham - Commits
- rG4ced470a31cb: Fix issue where GPR and FPR registers have overlapping byte offsets.
rLLDB233837: Fix issue where GPR and FPR registers have overlapping byte offsets.
rL233837: Fix issue where GPR and FPR registers have overlapping byte offsets.
Diff Detail
- Repository
- rL LLVM
Event Timeline
source/Plugins/Process/Utility/RegisterContextFreeBSD_x86_64.cpp | ||
---|---|---|
55 ↗ | (On Diff #22841) | This doesn't sound right, but I don't know enough about FreeBSD to dispute it. |
Looks good to me. I usually create assembler files that load all registers up with known values and then stop at a label like "stop_here" and debug the program and verify all registers are where they should be. It would be a good idea for us to start doing this for all targets we support.
I usually create assembler files that load all registers up with known
values and then stop at a label like "stop_here" and debug the program and
verify all registers are where they should be.
Does this mean a test like that already exists for OS X?
No, I do this when first debugging a new Process plug-in or architecture. I wasn't sure about the assembler portability so I never checked on in.
This causes >20 tests to segfault on FreeBSD.
The debug register implementation on FreeBSD is a bit different, see rL201706. I can work around it for now by moving DR_OFFSET's definition back into RegisterContextFreeBSD_x86_64.cpp and RegisterContextLinux_x86_64.cpp.
Whoops, I apologize. I'll fix it when I get to the office. The GPR/FPR
offset change doesn't cause any problems on FreeBSD right? I just sort of
just plopped a dummy UserArea in there for FreeBSD to compile. It would be
great if I could find where the Linux one came from, and where to get the
correct FreeBSD layout.
I'm happy to see this sort of cleanup happening and a little collateral damage is understandable. I've committed rL234048 as a temporary change to restore basic functionality and fix the buildbot; we'll want to investigate a bit further to come up with a clean fix as you describe.