This is an archive of the discontinued LLVM Phabricator instance.

Remove some ProcFileReader occurences
ClosedPublic

Authored by labath on Mar 14 2017, 7:53 AM.

Details

Summary

ProcFileReader is the cause of the dependency from Host to ProcessLinux
module. Since it's interface is also obsolete (ReadIntoDataBuffer is
trivially replaceable by llvm::MemoryBuffer functions and
ProcessLineByLine is trivially implementable with StringRefs), instead
of moving it around I'm planning to obliterate it. This is the first
step, where I remove a couple of occurences in linux/Host.cpp, and
modernize some code around that.

I have introduced linux/Support.h, which holds two utility functions
now, whose resposibility is to construct the appropriate proc file names

  • the only useful feature of ProcFileReader.

I add a couple of tests for these functions, and for
Host::GetProcessInfo. It's worth noting that these are the first
host-specific unit tests in lldb.

Diff Detail

Repository
rL LLVM

Event Timeline

labath created this revision.Mar 14 2017, 7:53 AM
zturner edited edge metadata.Mar 14 2017, 8:39 AM

Code looks much nicer than before!

source/Host/linux/Host.cpp
59–60 ↗(On Diff #91727)

Random thought. Someone should make a LinesIterator. (Not you, just a random thought like I said)

63–70 ↗(On Diff #91727)

Is it worth checking the return value of consumeInteger? Is it possible some fields might not be set / do you care about that?

145 ↗(On Diff #91727)

I'd use an early return here, but not a big deal.

166 ↗(On Diff #91727)

You can make this a bit shorter with ((llvm::Twine("/proc") + pid) + "/exe").toVector(ProcExe);

source/Host/linux/Host.cpp
63–70 ↗(On Diff #91727)

The data comes straight from the OS kernel. I am trusting it to supply the information correctly.

145 ↗(On Diff #91727)

I just moved that function around in this patch., I don't want to touch it now.

166 ↗(On Diff #91727)

ok

zturner accepted this revision.Mar 14 2017, 9:18 AM
This revision is now accepted and ready to land.Mar 14 2017, 9:18 AM
eugene accepted this revision.Mar 14 2017, 11:58 AM
eugene added inline comments.
source/Host/linux/Host.cpp
167 ↗(On Diff #91727)

std::string? Do we have any benefits from using 0 size stack allocated string here?

labath added inline comments.Mar 15 2017, 3:46 AM
source/Host/linux/Host.cpp
166 ↗(On Diff #91727)

Actually, that doesn't work as Twine's integral constructors are explicit.

167 ↗(On Diff #91727)

Not really, I was trying to be consistent with the ProcExe variable above, but I did not want to allocate PATH_MAX on the stack. I'll change it to std::string, hopefully that looks less weird.

This revision was automatically updated to reflect the committed changes.

For your interest. NetBSD will not use procfs for any operation.

Today I implemented reading the process map with sysctl(7):

https://github.com/NetBSD/pkgsrc-wip/commit/d4af36204feb616dd83f5f3ffb871a4b7274e5e0

procfs is used by SunOS.. but for regular debuggers they offer libproc - API in C.. and their debugging facilities are very different from Linux and BSD.