This is an archive of the discontinued LLVM Phabricator instance.

Move register reading form NativeProcessLinux to NativeRegisterContextLinux*
ClosedPublic

Authored by tberghammer on May 22 2015, 5:57 AM.

Details

Summary

Move register reading form NativeProcessLinux to NativeRegisterContextLinux*

This change reorganize the register read/write code inside lldb-server on Linux
with moving the architecture independent code into a new class called
NativeRegisterContextLinux and all of the architecture dependent code into the
appropriate NativeRegisterContextLinux_* class. As part of it the compilation of
the architecture specific register contexts are only compiled on the specific
architecture because they can't be used in other cases.

The purpose of this change is to remove a lot of duplicated code from the different
register contexts and to remove the architecture dependent codes from the global
NativeProcessLinux class.

Diff Detail

Repository
rL LLVM

Event Timeline

tberghammer retitled this revision from to Move register reading form NativeProcessLinux to NativeRegisterContextLinux*.
tberghammer updated this object.
tberghammer edited the test plan for this revision. (Show Details)
tberghammer added a subscriber: Unknown Object (MLST).
labath edited edge metadata.May 22 2015, 7:23 AM

Looks mostly good, but I have some comments.

source/Plugins/Process/Linux/NativeRegisterContextLinux_arm.h
10 ↗(On Diff #26317)

I'm not really sure what's the official preferred way, but I find excluding a file from compilation (via CMakeLists.txt) nicer than #ifdef-ing all its contents. I can appreciate the pain of maintaining multiple build systems though. Do we ever want to build this from XCode?

source/Plugins/Process/Linux/NativeThreadLinux.cpp
190 ↗(On Diff #26317)

I find these checks quite convoluted. I propose we do the following instead:

  1. In each NativeRegisterContextLinux_XXX.cpp implement the following function:
RegisterInfoInterface *CreateHostRegisterContext(...)
{
  // perform whatever checks you need
  return new RegisterContextLinux_XXX();
}
  1. Since we compile only one file at a time, this will automatically select the correct architecture
  2. This whole ifdef-switch becomes reg_interface = CreateHostRegisterContext(...);
  3. Take over the world.
248 ↗(On Diff #26317)

The same thing can be done here.

tberghammer edited edge metadata.

Move register context creation from NativeThreadLinux into the NativeRegisterContextLinux_* classes

tberghammer added inline comments.May 22 2015, 9:08 AM
source/Plugins/Process/Linux/NativeRegisterContextLinux_arm.h
10 ↗(On Diff #26317)

I checked it and we don't compile it with XCode but the current llvm build system only allow excluding files at directory level. I can move the register contexts into their own directory, but I prefer to do it with a separate commit so the history stay clean (move and change not always play together nicely)

source/Plugins/Process/Linux/NativeThreadLinux.cpp
190 ↗(On Diff #26317)

Done (also merged the two switch)

omjavaid edited edge metadata.May 25 2015, 1:56 AM

Hi Tamas,

Patch looks good overall.

I may not have a clear picture of overall design you have in mind So have a couple of questions:

Current implementation before this patch makes a register read/write as a process functionality accessed through PTRACE calls. Thats why it seemed to be implemented in nativeProcessLinux class. Now that we have ptrace calls spread all over different register contexts and nativeprocesslinux interface how are we providing synchronization among multiple ptrace calls? How process state (running/halted) information is being communicated to register context instances created by nativeThreadlinux instances.

Hi Omair,

All of the ptrace calls still have to go through NativeProcessLinux to do the synchronization (because ptrace have to be called from the same thread which did the exec or the attach) and the way it is implemented isn't change with this patch. Previously it was handled by executing operations only from NativeProcessLinux. After this change it will be possible to execute operations outside of the NativeProcessLinux class also with calling the newly introduced NativeProcessLinux::DoOperation method what will do the same synchronization what was there before.

labath accepted this revision.May 26 2015, 3:24 AM
labath edited edge metadata.

LGTM.

Wrt. Omair's questions, here are my thoughts:

Now that we have ptrace calls spread all over different register contexts and nativeprocesslinux interface how are we providing synchronization among multiple ptrace calls?

All PTRACE operations still go through NPL::DoOperation, which makes sure they execute on the correct thread deals with the synchronisation necessary to do that. What kind of synchronisation did you have in mind?

How process state (running/halted) information is being communicated to register context instances created by nativeThreadlinux instances.

Why do you need that information? I would say that this is the responsibility of the caller (NPL/NTL). E.g. it is clear that it is not possible to read registers if the thread is running, so the caller better make sure that the thread is stopped before he attempts to call ReadRegister()...

source/Plugins/Process/Linux/NativeRegisterContextLinux_arm.h
10 ↗(On Diff #26317)

Ok, let's leave this as-is for now.

source/Plugins/Process/Linux/NativeThreadLinux.cpp
190 ↗(On Diff #26317)

This looks much better. Thanks.

This revision is now accepted and ready to land.May 26 2015, 3:24 AM
This revision was automatically updated to reflect the committed changes.