The fix form sizes use to have two arrays: one for 4 byte addresses and in for 8 byte addresses. The table had an issue where DW_FORM_flag_present wasn't being represented as a fixed size form because its actual size _is_ zero and zero was used to indicate the form isn't fixed in size. Any code that needed to quickly access the DWARF had to get a FixedFormSizes instance using the address byte size.
This fix cleans things up by adding a DWARFFormValue::GetFixedSize() both as a static method and as a member function on DWARFFormValue. It correctly can indicate if a form size is zero. This cleanup is a precursor to a follow up patch where I hope to speed up DWARF parsing.
I verified performance doesn't regress by loading hundreds of DWARF files and setting a breakpoint by file and line and by name in files that do not have DWARF indexes. Performance remained consistent between the two approaches.
Differential Revision: https://reviews.llvm.org/D62416
llvm-svn: 361675
The script phase to do Options.td -> Options.inc was
wrong (missing the "include" directory) so the rule didn't
get run when Options.td changed.
llvm-svn: 360304
Checking this in for Antonio Afonso:
This diff changes the function LineEntry::GetSameLineContiguousAddressRange so that it also includes function calls that were inlined at the same line of code.
My motivation is to decrease the step over time of lines that heavly rely on inlined functions. I have multiple examples in the code base I work that makes a step over stop 20 or mote times internally. This can easly had up to step overs that take >500ms which I was able to lower to 25ms with this new strategy.
The reason the current code is not extending the address range beyond an inlined function is because when we resolve the symbol at the next address of the line entry we will get the entry line corresponding to where the original code for the inline function lives, making us barely extend the range. This then will end up on a step over having to stop multiple times everytime there's an inlined function.
To check if the range is an inlined function at that line I also get the block associated with the next address and check if there is a parent block with a call site at the line we're trying to extend.
To check this I created a new function in Block called GetContainingInlinedBlockWithCallSite that does exactly that. I also added a new function to Declaration for convinence of checking file/line named CompareFileAndLine.
To avoid potential issues when extending an address range I added an Extend function that extends the range by the AddressRange given as an argument. This function returns true to indicate sucess when the rage was agumented, false otherwise (e.g.: the ranges are not connected). The reason I do is to make sure that we're not just blindly extending complete_line_range by whatever GetByteSize() we got. If for some reason the ranges are not connected or overlap, or even 0, this could be an issue.
I also added a unit tests for this change and include the instructions on the test itself on how to generate the yaml file I use for testing.
Differential Revision: https://reviews.llvm.org/D61292
llvm-svn: 360071
Summary:
After the last round of cleanups, this script was almost a no-op. The
only piece of functionality that remained was the one which tried to
make the swig-generated function signatures more pythonic.
The "tried" part is important here, as it wasn't doing a really good job
and the end result was not valid python nor c (e.g.,
SetExecutable(SBAttachInfo self, str const * path)).
Doing these transformations another way is not possible, as these
signatures are generated by swig, and not present in source. However,
given that this is the only reason why we need a swig post-process step,
and that the current implementation is pretty sub-optimal, this patch
simply abandons the signature fixup idea, and chooses to simplify our
build process instead.
Reviewers: amccarth, jingham, clayborg
Subscribers: mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D61000
llvm-svn: 359092
"apple-latest" which llvm uses to indicate the newest supported ISA.
Add a unit test; I'm only testing an armv8.1 instruction in this
unit test which would already be disassembled correctly because we
set the disassembler to ARM v8.2 mode, but it ensures that nothing
has been broken by adding this cpu spec.
<rdar://problem/38714781>
llvm-svn: 355578
When running the test suite with the instrumentation macros, I noticed
two lldb-mi tests regressed. The issue was the copy constructor of
SBLineEntry. Without the macros the returned value would be elided, but
with the macros the copy constructor was called. The latter using ::IsValid
to determine whether the underlying opaque pointer should be set. This
is likely a remnant of when ::IsValid would only check the validity of the
smart pointer. In SBLineEntry however, it actually forwards to
LineEntry::IsValid().
So what happened here was that because of the macros the copy
constructor was called. The opaque pointer was valid but the LineEntry
didn't consider itself valid. So the copied-to object ended up default
initialized.
This patch replaces all checks for IsValid in copy (assignment)
constructors with checks for the opaque pointer itself.
Differential revision: https://reviews.llvm.org/D58946
llvm-svn: 355458
Summary:
The current install-clang-headers target installs clang's resource
directory headers. This is different from the install-llvm-headers
target, which installs LLVM's API headers. We want to introduce the
corresponding target to clang, and the natural name for that new target
would be install-clang-headers. Rename the existing target to
install-clang-resource-headers to free up the install-clang-headers name
for the new target, following the discussion on cfe-dev [1].
I didn't find any bots on zorg referencing install-clang-headers. I'll
send out another PSA to cfe-dev to accompany this rename.
[1] http://lists.llvm.org/pipermail/cfe-dev/2019-February/061365.html
Reviewers: beanz, phosek, tstellar, rnk, dim, serge-sans-paille
Subscribers: mgorny, javed.absar, jdoerfert, #sanitizers, openmp-commits, lldb-commits, cfe-commits, llvm-commits
Tags: #clang, #sanitizers, #lldb, #openmp, #llvm
Differential Revision: https://reviews.llvm.org/D58791
llvm-svn: 355340
When the debugger is run in sync mode, you need to
be able to tell whether a hijacked resume is for some
special purpose (like waiting for the SIGSTOP on attach)
or just to perform a synchronous resume. Target::Launch was doing
that wrong, and that caused stop-hooks on process launch
in source files to behave incorrectly.
<rdar://problem/48115661>
Differential Revision: https://reviews.llvm.org/D58727
llvm-svn: 355213
As per the discussion on the mailing list:
http://lists.llvm.org/pipermail/lldb-commits/Week-of-Mon-20190218/048007.html
This commit implements option (3):
> Go back to initializing the reproducer before the rest of the debugger.
> The method wouldn't be instrumented and guarantee no other SB methods are
> called or SB objects are constructed. The initialization then becomes part
> of the replay.
Differential revision: https://reviews.llvm.org/D58410
llvm-svn: 354631
A handful of test files had been added to lldb, but not to the
appropriate target in the Xcode project. So they weren't being
run in the Xcode gtest run. Add them here.
llvm-svn: 352114
We're linking against libcompression all the time now, we don't need to
fall back to zlib. zlib support will still be used when lldb is built on
linux et al systems, so I'm not removing any of the source support, but
when built on darwin with xcode, we'll be using libcompression.
llvm-svn: 349572
systems. It has been available in the OS over over three years
now. If lldb doesn't link against -lcompression, it should be an
error.
Allocate a scratch buffer for libcompression to use when decoding
packets, instead of it having to allocate & free one on every call.
Fix a typeo with the size of the buffer that compression_decode_buffer()
is expanding into.
<rdar://problem/41601084>
llvm-svn: 349563
Breakpad creates minidump files that sometimes have:
- linux maps textual content
- no MemoryInfoList
Right now unless the file has a MemoryInfoList we get no region information.
This patch:
- reads and caches the memory region info one time and sorts it for easy subsequent access
- get the region info from the best source in this order:
- linux maps info (if available)
- MemoryInfoList (if available)
- MemoryList or Memory64List
- returns memory region info for the gaps between regions (before the first and after the last)
Differential Revision: https://reviews.llvm.org/D55522
llvm-svn: 349182
Jason Molenda