This is an archive of the discontinued LLVM Phabricator instance.

Create x86 specific NativeRegisterContextLinux
AbandonedPublic

Authored by tberghammer on Feb 16 2015, 4:22 AM.

Details

Summary

Create x86 specific NativeRegisterContextLinux

Previously some part of the x86 specific code was shuffled into the x86_64 specific native register context linux without full functionality. This CL moves the common part into a new common base class (NativeRegisterContextLinux) and creates a new x86 specific subclass contatining the missing functionality and to provide better separation.

Diff Detail

Event Timeline

tberghammer retitled this revision from to Create x86 specific NativeRegisterContextLinux.
tberghammer updated this object.
tberghammer edited the test plan for this revision. (Show Details)
tberghammer added reviewers: ovyalov, chaoren, vharron.
tberghammer added a subscriber: Unknown Object (MLST).

Add newly created files to the xcode project

chaoren edited edge metadata.Feb 16 2015, 9:56 AM

Previously some part of the x86 specific code was shuffled into the x86_64
specific native register context linux without full functionality. This CL
moves the common part into a new common base class
(NativeRegisterContextLinux) and creates a new x86 specific subclass
contatining the missing functionality and to provide better separation.

What was the missing functionality? It would be nice to have the reorg and
the new code in separate diffs.

The main issue was that the 32 bit version used the constants from the 64 bit version what wasn't valid in that scope. The two major misuse was using m_gpr_x86_64 for i386 where the size isn't match with the requested size and using wrong indexes for the debug registers for setting the watch points.
Since this CL I found one more issue with register handling but I will address that with an other CL (effect both x64 and x86).

using wrong indexes for the debug registers for setting the watch points.

Ah, that was an error on my part. I fixed it in this CL:
http://reviews.llvm.org/D7635

I'm not sure I understand the first issue.

Previously the "uint64_t m_gpr_x86_64[k_num_gpr_registers_x86_64];" variable was used to store the value of the gpr registers for both x86 and for x64 contexts what isn't a problem until k_num_gpr_registers_x86_64 >= k_num_gpr_registers_i386 (currently true) and we don't use sizeof on it but I think it is a bit of a design flow.
If your fix for the debug registers will go in then this CL only contains the separation.

I also tried to separate i386 from x86_64, but it seemed a bit unnecessary
since the only real difference is the register sets.

The m_gpr_x86_64 does bother me a bit too, but I imagine
k_num_gpr_registers_x86_64

k_num_gpr_registers_i386 would always be true, and we should probably

always use GetRegisterInfoInterface().GetGPRSize() instead of sizeof.

How does this look instead?

union {

uint64_t m_gpr_i386[k_num_gpr_registers_i386];
uint64_t m_gpr_x86_64[k_num_gpr_registers_x86_64];

} m_gpr;

In any case, let's get some more opinions on this first.

I still prefer to separate it into multiply classes (not necessarily the way I did it here) because the multiple switch statement and the union looks bad for me especially if we consider that we plan to add a few more register context to the system (arm32, arm64, mips, ...)

One more new feature in this CL is a new GetUserRegisterCount function which one is handle the possibility of some missing floating point register on 32 bit architectures (sorry for not mentioning it before)

tberghammer abandoned this revision.Feb 17 2015, 7:00 AM

Abandon as the current structure don't support the easy addition of new (more different) architectures such as arm32 or arm64.
I am working on the design of a new class layout to make this separation cleaner and add arm support in a clean way.