These three classes have no external dependencies, but they are used
from various low-level APIs. Moving them down to Utility improves
overall code layering (although it still does not break any particular
dependency completely).
The XCode project will need to be updated after this change.
Differential Revision: https://reviews.llvm.org/D49740
llvm-svn: 339127
This is intended as a clean up after the big clang-format commit
(r280751), which unfortunately resulted in many of the comment
paragraphs in LLDB being very hard to read.
FYI, the script I used was:
import textwrap
import commands
import os
import sys
import re
tmp = "%s.tmp"%sys.argv[1]
out = open(tmp, "w+")
with open(sys.argv[1], "r") as f:
header = ""
text = ""
comment = re.compile(r'^( *//) ([^ ].*)$')
special = re.compile(r'^((([A-Z]+[: ])|([0-9]+ )).*)|(.*;)$')
for line in f:
match = comment.match(line)
if match and not special.match(match.group(2)):
# skip intentionally short comments.
if not text and len(match.group(2)) < 40:
out.write(line)
continue
if text:
text += " " + match.group(2)
else:
header = match.group(1)
text = match.group(2)
continue
if text:
filled = textwrap.wrap(text, width=(78-len(header)),
break_long_words=False)
for l in filled:
out.write(header+" "+l+'\n')
text = ""
out.write(line)
os.rename(tmp, sys.argv[1])
Differential Revision: https://reviews.llvm.org/D46144
llvm-svn: 331197
Summary:
We cannot call process_up->SetState() inside
the NativeProcessNetBSD::Factory::Launch
function because it triggers a NULL pointer
deference.
The generic code for launching a process in:
GDBRemoteCommunicationServerLLGS::LaunchProcess
sets the m_debugged_process_up pointer after
a successful call to m_process_factory.Launch().
If we attempt to call process_up->SetState()
inside a platform specific Launch function we
end up dereferencing a NULL pointer in
NativeProcessProtocol::GetCurrentThreadID().
Use the proper call process_up->SetState(,false)
that sets notify_delegates to false.
Sponsored by <The NetBSD Foundation>
Reviewers: labath, joerg
Reviewed By: labath
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D42868
llvm-svn: 324234
Summary:
The ObjectFile class was used to determine the architecture of a running
process by inspecting it's main executable. There were two issues with
this:
- it's in the wrong layer
- the call can be very expensive (it can end up computing the crc of the
whole file).
Since the process is running on the host, ideally we would be able to
just query the data straight from the OS like darwin does, but there
doesn't seem to be a reasonable way to do that. So, this fixes the
layering issue by using the llvm object library to inspect the file.
Since we know the process is already running on the host, we just need
to peek at a few bytes of the elf header to determine whether it's 32-
or 64-bit (which should make this faster as well).
Pretty much the same logic was implemented in
NativeProcessProtocol::ResolveProcessArchitecture, so I delete this
logic and replace calls with GetProcessInfo.
Reviewers: eugene, krytarowski
Subscribers: mgorny, hintonda, lldb-commits
Differential Revision: https://reviews.llvm.org/D42488
llvm-svn: 323637
Summary:
This commit removes the concrete_frame_idx member from
NativeRegisterContext and related functions, which was always set to
zero and never used.
I also change the native thread class to store a NativeRegisterContext
as a unique_ptr (documenting the ownership) and make sure it is always
initialized (most of the code was already blindly dereferencing the
register context pointer, assuming it would always be present -- this
makes its treatment consistent).
Reviewers: eugene, clayborg, krytarowski
Subscribers: aemerson, sdardis, nemanjai, javed.absar, arichardson, kristof.beyls, kbarton, uweigand, alexandreyy, lldb-commits
Differential Revision: https://reviews.llvm.org/D39837
llvm-svn: 317881
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.
Reviewers: eugene, krytarowski
Subscribers: javed.absar, lldb-commits
Differential Revision: https://reviews.llvm.org/D39733
llvm-svn: 317779
Summary:
The NativeThread class is useless without the containing process (and in
some places it is already assuming the process is always around). This
makes it clear that the NativeProcessProtocol is the object owning the
threads, and makes the destruction order deterministic (first threads,
then process). The NativeProcess is the only thing holding a thread
unique_ptr, and methods that used to hand out thread shared pointers now
return raw pointers or references.
Reviewers: krytarowski, eugene
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D35618
llvm-svn: 316007
Summary:
The usage of shared_from_this forces us to separate construction and
initialization phases, because shared_from_this() is not available in
the constructor (or destructor). The shared semantics are not necessary,
as we always have a clear owner of the native process class
(GDBRemoteCommunicationServerLLDB object). Even if we need shared
semantics in the future (which I think we should strongly avoid),
reverting this will not be necessary -- the owners can still easily
store the native process object in a shared pointer if they really want
to -- this just prevents the knowledge of that from leaking into the
class implementation.
After this a NativeThread object will hold a reference to the parent
process (instead of a weak_ptr) -- having a process instance always
available allows us to simplify some logic in this class (some of it was
already simplified because we were asserting that the process is
available, but this makes it obvious).
Reviewers: krytarowski, eugene, zturner
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D35123
llvm-svn: 308282
Summary:
This replaces the static functions used for creating
NativeProcessProtocol instances with a factory pattern, and modernizes
the interface of the new class in the process -- I use llvm::Expected
instead of the Status+value combo. I also move some of the common code
(like the Delegate registration into the base class). The new
arrangement has multiple benefits:
- it removes the NativeProcess*** dependency from Process/gdb-remote
(which for example means that liblldb no longer pulls in this code).
- it enables unit testing of the GDBRemoteCommunicationServerLLGS class
(by providing a mock Native Process).
- serves as another example on how to use the llvm::Expected class (I
couldn't get rid of the Initialize-type functions completely here
because of the use of shared_from_this, but that's the next thing on
my list here)
Tests still pass on Linux and I've made sure NetBSD compiles after this.
Reviewers: zturner, eugene, krytarowski
Subscribers: srhines, lldb-commits, mgorny
Differential Revision: https://reviews.llvm.org/D33778
llvm-svn: 307390
Summary:
A number of places were trying to decode the result of wait(). Add a simple
utility function that does that and a struct that encapsulates the
decoded result. Then also provide a pretty-printer for that class.
Reviewers: zturner, krytarowski, eugene
Subscribers: lldb-commits, mgorny
Differential Revision: https://reviews.llvm.org/D33998
llvm-svn: 305689
This renames the LLDB error class to Status, as discussed
on the lldb-dev mailing list.
A change of this magnitude cannot easily be done without
find and replace, but that has potential to catch unwanted
occurrences of common strings such as "Error". Every effort
was made to find all the obvious things such as the word "Error"
appearing in a string, etc, but it's possible there are still
some lingering occurences left around. Hopefully nothing too
serious.
llvm-svn: 302872
Summary:
Include initial support for:
- single step mode (PT_STEP)
- single step trap handling (TRAP_TRACE)
- exec() trap (TRAP_EXEC)
- add placeholder interfaces for FPR
- initial code for NetBSD core(5) files
- minor tweaks
While there improve style of altered elf-core/ files.
This code raises the number of passing tests on NetBSD to around 50% (600+/1200+).
The introduced code is subject to improve afterwards for additional features and bug fixes.
Sponsored by <The NetBSD Foundation>
Reviewers: labath, joerg, emaste, kettenis
Reviewed By: labath
Subscribers: srhines, #lldb
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D31450
llvm-svn: 299109
Summary:
This patch is a stripped down from features a NetBSD process
code (patch is kept under 2k LOC). This code has assumption that
there is only one thread within a debugged process. The only
debugger trap supported is software breakpoint (TRAP_BRKPT).
The generic platform code requires to add dummy function for
watchpoints etc. These functions are currently empty.
This code is not the final platform support as is and it's treated as
a base to extend, refactor and address issues afterwards.
Supported features:
- handle software breakpoints,
- correctly attach to a tracee,
- support NetBSD specific ptrace(2),
- monitor process termination,
- monitor SIGTRAP events,
- monitor SIGSTOP events,
- monitor other signals events,
- resume the whole process,
- get memory region info perms,
- read memory from tracee,
- write memory to tracee,
- read ELF AUXV,
- x86_64 GPR read and write code
For the generic framework include:
- halt,
- detach,
- signal,
- kill,
- allocatememory,
- deallocatememory,
- update threads,
- getarchitecture,
- getfileloadaddress,
- and others.
This code has preliminary AddThread code.
Out of interest in this patch:
- exec() traps,
- hardware debug register traps,
- single step trap,
- thread creation/termination trap,
- process fork(2), vfork(2) and vfork(2) done traps,
- syscall entry and exit trap,
- threads,
- FPR registers,
- retrieving tracee's thread name,
- non x86_64 support.
This code can be used to start a hello world application and trace it.
This code can be used by other BSD systems as a starting point to get similar
capabilities.
Sponsored by <The NetBSD Foundation>
Reviewers: emaste, joerg, kettenis, labath
Subscribers: mgorny, #lldb
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D31374
llvm-svn: 298953
Summary:
This is the base for introduction of further features to support Process Tracing on NetBSD, in local and remote setup.
This code is also a starting point to synchronize the development with other BSDs. Currently NetBSD is ahead and other systems can catch up.
Sponsored by <The NetBSD Foundation>
Reviewers: emaste, joerg, kettenis, labath
Reviewed By: labath
Subscribers: mgorny, #lldb
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D31138
llvm-svn: 298408
Pavel Labath