This is an archive of the discontinued LLVM Phabricator instance.

Simplify NativeProcessProtocol::GetArchitecture/GetByteOrder
ClosedPublic

Authored by labath on Nov 7 2017, 7:37 AM.

Details

Summary

These functions used to return bool to signify whether they were able to
retrieve the data. This is redundant because the ArchSpec and ByteOrder
already have their own "invalid" states, *and* because both of the
current implementations (linux, netbsd) can always provide a valid
result.

This allows us to simplify bits of the code handling these values.

Diff Detail

Repository
rL LLVM

Event Timeline

labath created this revision.Nov 7 2017, 7:37 AM
eugene added inline comments.Nov 7 2017, 12:12 PM
include/lldb/Host/common/NativeProcessProtocol.h
104 ↗(On Diff #121903)

Why return reference instead of a value?

labath added inline comments.Nov 7 2017, 1:45 PM
include/lldb/Host/common/NativeProcessProtocol.h
104 ↗(On Diff #121903)

I'd actually reverse that: Why value instead of a reference ? :D

Returning by reference allows us to potentially avoid a copy. It does mean that the process object has to hold the archspec as a member, but that is currently not an issue, and we can always change that.

krytarowski edited edge metadata.Nov 7 2017, 1:47 PM

The NetBSD part looks good.

clayborg requested changes to this revision.Nov 7 2017, 3:06 PM
clayborg added a subscriber: clayborg.

Looks fine. Seems like you should use your a const reference in a few places and this will be good to go?

source/Plugins/Process/Linux/NativeRegisterContextLinux_mips64.cpp
1036 ↗(On Diff #121903)

Avoid a copy here by using a const reference?

source/Plugins/Process/NetBSD/NativeThreadNetBSD.cpp
147 ↗(On Diff #121903)

Void a copy here and use a const reference?

This revision now requires changes to proceed.Nov 7 2017, 3:06 PM
eugene added inline comments.Nov 7 2017, 5:07 PM
include/lldb/Host/common/NativeProcessProtocol.h
104 ↗(On Diff #121903)

Why value instead of a reference ? :D

IMO returning by value is a default option, for 2 reasons:

  1. References and pointers introduce implicit lifetime dependencies (prone to use-after-free)
  2. Value can change over time, and client might not expect it to happen.

Potentially avoid a copy in place where a copy was made previously and didn't seem to hurt anybody seems like a bad trade-off for one more place where we can get a dangling pointer.

If it isn't expensive to copy, then we should probably just return by value.

labath added inline comments.Nov 8 2017, 3:34 AM
include/lldb/Host/common/NativeProcessProtocol.h
104 ↗(On Diff #121903)

That's kinda true, but simply returning by reference does not force you to hold on to the reference everywhere. It just leaves the decision up to the caller -- if you put the result in a variable, you get a copy; if you put it in a reference (or just directly use it) then you don't. And if I see something like const ArchSpec &arch = ..., I will take a good look at what's the lifetime of the object this refers to.

I'm not what you base your "default" statement on, but it certainly does not seem to be the default in llvm. Just look at llvm::Triple::str() -- it returns a reference to the string object private member.

ArchSpec is 56 bytes long (on x86_64), and it contains a string (potential heap allocation), so it's not exactly cheap to copy. GetByteOrder() is called on every register read, so it would be great to avoid copying an ArchSpec just to read a register. I'm not saying this will make register reading blazingly fast, but I think it's a step in the right direction.

labath updated this revision to Diff 122050.Nov 8 2017, 3:41 AM
labath edited edge metadata.
labath marked an inline comment as done.

Avoid a couple of ArchSpec copies, as suggested.

clayborg accepted this revision.Nov 8 2017, 9:19 AM
This revision is now accepted and ready to land.Nov 8 2017, 9:19 AM
This revision was automatically updated to reflect the committed changes.