This is an archive of the discontinued LLVM Phabricator instance.

[lldb] Add dummy field to RegisterInfo for register flags use later
ClosedPublic

Authored by DavidSpickett on Mar 8 2023, 3:17 AM.

Details

Summary

This structure is supposed to be trivial, so we cannot simply do
"= nullptr;" on the new member. Doing that means you are non trivial,
regardless of whether you emulate the previously implied constructor somehow.

The next option is to update every use of brace initialisation.

Given that this is some hundreds of lines, this change just adds a dummy
pointer that is set to nullptr. Subsequent changes will actually use that
to point to register flags information.

Note: This change is not clang-format-ted because it changes a bunch of
areas that are not themselves formatted. It would just add noise.

Diff Detail

Event Timeline

DavidSpickett created this revision.Mar 8 2023, 3:17 AM
Herald added a project: Restricted Project. · View Herald TranscriptMar 8 2023, 3:17 AM
DavidSpickett requested review of this revision.Mar 8 2023, 3:17 AM
This revision is now accepted and ready to land.Mar 9 2023, 12:45 PM
JDevlieghere added inline comments.Mar 20 2023, 1:59 PM
lldb/source/Plugins/ABI/ARM/ABIMacOSX_arm.cpp
57–68

Would using a .def file make this easier to maintain?

DavidSpickett added inline comments.Mar 21 2023, 2:43 AM
lldb/source/Plugins/ABI/ARM/ABIMacOSX_arm.cpp
57–68

Almost certainly, do you mean in general? Half of these files are using some macro to make the defs already, one could probably generalise that. You'd end up with a sort of constructor for RegisterInfo, but it's a macro. So if some file wants to diverge, it can.

Let me see what I can do about that, though I think it would be best done in a new patch.

JDevlieghere accepted this revision.Mar 21 2023, 9:35 AM

LGTM

lldb/source/Plugins/ABI/ARM/ABIMacOSX_arm.cpp
57–68

Yeah, I meant the g_register_infos as a whole. Tablegen would be an option too, but that might be overkill for this. Separate patch sounds fair.