This is an archive of the discontinued LLVM Phabricator instance.

[lldb] Support querying registers via generic names without alt_names
ClosedPublic

Authored by mgorny on Aug 23 2021, 6:46 AM.

Details

Summary

Update GetRegisterInfoByName() methods to support getting registers
by a generic name independently of alt_name entries in the register
context. This makes it possible to use generic names when interacting
with gdbserver (that does not supply alt_names). It also makes it
possible to remove some of the duplicated information from register
context declarations and/or use alt_names for another purpose.

Diff Detail

Event Timeline

mgorny requested review of this revision.Aug 23 2021, 6:46 AM
mgorny created this revision.
mgorny updated this revision to Diff 370785.Sep 5 2021, 1:44 AM

Preserve the prior (probably accidental) behavior of generic names taking precedence over later registers with the same name (e.g. generic sp alias taking precedence over 16-bit sp pseudo-register).

mgorny updated this revision to Diff 371134.Sep 7 2021, 11:27 AM

The test requires building with X86 target.

I'm not sure we should be preserving this behavior for the native register context. User-provided strings should not make it there, and code should really be retrieving the registers in some other way (like via the LLDB_REGNUM_GENERIC_*** constants).

It would also be nice to follow this up by actually removing the generic altnames from register definitions, for cases where they don't match architecturally defined names.

I'm not sure we should be preserving this behavior for the native register context. User-provided strings should not make it there, and code should really be retrieving the registers in some other way (like via the LLDB_REGNUM_GENERIC_*** constants).

Could you rephrase this comment to indicate the requested change, if any? ;-)

It would also be nice to follow this up by actually removing the generic altnames from register definitions, for cases where they don't match architecturally defined names.

That was roughly my plan, presuming you like the idea. Should I include this in the same commit or separately for each platform?

I'm not sure we should be preserving this behavior for the native register context. User-provided strings should not make it there, and code should really be retrieving the registers in some other way (like via the LLDB_REGNUM_GENERIC_*** constants).

Could you rephrase this comment to indicate the requested change, if any? ;-)

Well.. the comment was open ended, because my thoughts on this are quite open ended as well.. :) But if I wanted to be more precise, I suppose it boils down to this:

  • Is the NativeRC change there for a particular reason (like, does anything break if you leave it out)?
  • Do _you_ agree with my assessment of its necessity?

If there's no reason for its presence, and you don't see it as necessary, then I'd like to remove it. If not, let's talk.

It would also be nice to follow this up by actually removing the generic altnames from register definitions, for cases where they don't match architecturally defined names.

That was roughly my plan, presuming you like the idea. Should I include this in the same commit or separately for each platform?

Sounds good. I think we should do it as a separate patch. Whether it's one or more of them depends on how large they get...

I'm not sure we should be preserving this behavior for the native register context. User-provided strings should not make it there, and code should really be retrieving the registers in some other way (like via the LLDB_REGNUM_GENERIC_*** constants).

Could you rephrase this comment to indicate the requested change, if any? ;-)

Well.. the comment was open ended, because my thoughts on this are quite open ended as well.. :) But if I wanted to be more precise, I suppose it boils down to this:

  • Is the NativeRC change there for a particular reason (like, does anything break if you leave it out)?
  • Do _you_ agree with my assessment of its necessity?

If there's no reason for its presence, and you don't see it as necessary, then I'd like to remove it. If not, let's talk.

Ah, now I get what you mean. To be honest, I've done that because I wasn't sure whether there isn't any code relying on that. I guess I'll try removing it and see if any tests fail.

Ok, so I've done some testing and indeed Native* part doesn't seem necessary.

However, after removing the aliases from x86_64 target def, there are two test regressions. The two following snippets no longer seem to work:

eip = frame.FindRegister("pc")
sp_value = frame0.FindValue("sp", lldb.eValueTypeRegister)

This doesn't seem to work anymore. Should I attempt to fix the API to make grabbing these registers by name work again, or should I try to modify the tests to grab these registers via generic reg nums?

These are pretty much the SB equivalents of register read, and they should keep working

mgorny updated this revision to Diff 371941.Sep 10 2021, 9:39 AM

Fixed SBFrame stuffs. While at it, changed ValueObjectRegister to take const RegisterInfo * instead of the index, since it's almost always what it really wants.

labath accepted this revision.Sep 13 2021, 1:38 AM
labath added inline comments.
lldb/source/API/SBFrame.cpp
636–640

I like this.

lldb/source/Target/RegisterContext.cpp
57–59

This isn't just "consistent with" generic aliases taking precedence. This is actually the implementation of that precedence (at least, after we remove the aliases in the other patch. This should just state as a fact that we want the aliases to take priority. The historic trivia can go into the commit message.

This revision is now accepted and ready to land.Sep 13 2021, 1:38 AM
mgorny marked 2 inline comments as done.Sep 13 2021, 2:29 AM
This revision was landed with ongoing or failed builds.Sep 13 2021, 4:05 AM
This revision was automatically updated to reflect the committed changes.
Herald added a project: Restricted Project. · View Herald TranscriptSep 13 2021, 4:05 AM