Initial implementation of support for tracking
[RenderScript Reductions](https://developer.android.com/guide/topics/renderscript/compute.html#reduction-in-depth)
With this patch, `language renderscript module dump` properly lists reductions
that are part of loaded RenderScript modules as well the the consituent
functions and their roles, within the reduction.
This support required new tracking mechanisms for the `#pragma(reduce)`
mechanism, and extension of `RSModuleDescriptor::ParseRSInfo` to support
the metadata output by `bcc`. This work was also an opportunity to
refactor/improve parse code:
- `RSModuleDescriptor::ParseExportReduceCount` now has a complete
implementation and the debugger can correctly track reductions on
receipt of a module hook.
- `RSModuleDescriptor::Dump` now dumps Reductions as well as `ForEach`
kernels. Also, fixed indentation of the output, and made indentation
groupings in the source clearer.
- `RSModuleDescriptor::ParseRSInfo` now returns true if the `".rs.info"`
packet has nonzero linecount, rather than rejecting RenderScripts that
don't contain kernels (an unlikely situation, but possibly valid). This
was changed because scripts that only contained reductions were not
being tracked in `RenderScriptRuntime::LoadModule`.
- Refactor `RSModuleInfo::ParseRSInfo` and add reduction spec parser stub
- Prepared ParseRSInfo to more easily be able to add new parser types
- Use llvm::StringRef and llvm::StringMap helpers to make the parsing code cleaner
- factor out forEachCount, globalVarCount, and pragmaCount parsing block to their own methods
- Add ExportReduceCount Parser
- Use `llvm::StringRef` in `RSKernelDescriptor` constructor
- removed now superfluous `MAXLINE` macros as we've switched from `const
char *` to `llvm::StringRef`
llvm-svn: 281717
This makes the code easier to grok, and since this is a very low
level function it also is very helpful to have this take a StringRef
since it means anyone higher up the chain who has a StringRef would
have to first convert it to a null-terminated string. This way it
can work equally well with StringRefs or const char*'s, which will
enable the conversion of higher up functions to StringRef.
Tested on Windows, Linux, and OSX and saw no regressions.
llvm-svn: 281642
It is a new attribute emitted by clang as a GNU extension and will
be part of Dwarf5. The purpose of the attribute is to specify a compile
unit level base value for all DW_AT_ranges to reduce the number of
relocations have to be done by the linker.
Fixes (at least partially): https://llvm.org/pr28826
Differential revision: https://reviews.llvm.org/D24514
llvm-svn: 281595
Thanks to Zachary Turner for the suggestion. It's distasteful that the actual
type of the lambda can't be spelled out, but it should be evident from the
definition of the lambda body.
llvm-svn: 281536
Moved the guts of the code from CommandObjectBreakpoint to Target (should
have done it that way in the first place.) Added an SBBreakpointList class
so there's a way to specify which breakpoints to serialize and to report the
deserialized breakpoints.
<rdar://problem/12611863>
llvm-svn: 281520
Summary:
This patch uses the instruction CPUID to verify that FXSAVE, XSAVE, AVX
and MPX are supported by the target hardware. In case the HW supports XSAVE,
and at least one of the extended register sets, it further checks if the
target software has the kernel support for such features, by verifying that
their XSAVE part is correctly managed.
Differential Revision: https://reviews.llvm.org/D24559
llvm-svn: 281507
I'm was trying to do some cleanup and code modernization and in
doing so I needed to change ParseMachCPUDashSubtypeTriple to take
a StringRef. To ensure I don't break anything, I'm adding some
unit tests for this function. As a side benefit, this also expands
test coverage of this function to all platforms, since in general
this code would rarely be exercised on non Mac platforms, and never
in the test suite.
llvm-svn: 281387
Plumb unique_ptrs<> all the way through the baton interface.
NFC, this is a minor improvement to remove the possibility of an
accidental pointer ownership issue.
Reviewed By: jingham
Differential Revision: https://reviews.llvm.org/D24495
llvm-svn: 281360
Summary:
Added parsing of the MiscInfo data stream.
The main member of it that we care about is the process_id
On Linux generated Minidump (from breakpad) we don't have
the MiscInfo, we have the /proc/$pid/status from where we can get the
pid.
Also parsing the module list - the list of all of the loaded
modules/shared libraries.
Parsing the exception stream.
Parsing MinidumpStrings.
I have unit tests for all of that.
Also added some tests using a Minidump generated from Windows tools (not
from breakpad)
Reviewers: labath, zturner
Subscribers: beanz, lldb-commits
Differential Revision: https://reviews.llvm.org/D24385
llvm-svn: 281348
Still to come:
1) SB API's
2) Testcases
3) Loose ends:
a) serialize Thread options
b) serialize Exception resolvers
4) "break list --file" should list breakpoints contained in a file and
"break read -f 1 3 5" should then read in only those breakpoints.
<rdar://problem/12611863>
llvm-svn: 281273
The class is only used in the debugserver. The rest of lldb has the StringExtractor class.
Xcode project will need to be updated after this.
llvm-svn: 281226
Summary:
It fixes the following compile warnings:
1. '0' flag ignored with precision and ‘%d’ gnu_printf format
2. enumeral and non-enumeral type in conditional expression
3. format ‘%d’ expects argument of type ‘int’, but argument 4 has type ...
4. enumeration value ‘...’ not handled in switch
5. cast from type ‘const uint64_t* {aka ...}’ to type ‘int64_t* {aka ...}’ casts away qualifiers
6. extra ‘;’
7. comparison between signed and unsigned integer expressions
8. variable ‘register_operand’ set but not used
9. control reaches end of non-void function
Reviewers: jingham, emaste, zturner, clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D24331
llvm-svn: 281191
This change does the following:
* Changes the signature for the continuation delegate method that handles
async structured data from accepting an already-parsed structured data
element to taking just the packet contents.
* Moves the conversion of the JSON-async: packet contents from
GDBRemoteClientBase to the continuation delegate method.
* Adds a new unit test for verifying that the $JSON-asyc: packets get
decoded and that the decoded packets get forwarded on to the delegate
for further processing. Thanks to Pavel for making that whole section of
code easily unit testable!
* Tightens up the packet verification on reception of a $JSON-async:
packet contents. The code prior to this change is susceptible to a
segfault if a packet is carefully crafted that starts with $J but
has a total length shorter than the length of "$JSON-async:".
Reviewers: labath, clayborg, zturner
Differential Revision: https://reviews.llvm.org/D23884
llvm-svn: 281121
Summary:
LLVM guys did some clean-up of the Attribute getters/setters
and because of that the build was failing.
Reviewers: ldrumm
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D24382
llvm-svn: 281030
The switch coveres all possible values. If a new one is added in the
future the compiler will start warning, providing a notification that
the switch needs updating.
llvm-svn: 280933
Summary:
- Added an API to public interface that provides permissions (RWX) of
individual sections of an object file
- Earlier, there was no way to find out this information through SB
APIs
- A possible use case of this API is:
when a user wants to know the sections that have executable machine
instructions and want to write a tool on top of LLDB based on this
information
- Differential Revision: https://reviews.llvm.org/D24251
llvm-svn: 280924
Summary:
This adds the jModulesInfo packet, which is the equivalent of qModulesInfo, but it enables us to
query multiple modules at once. This makes a significant speed improvement in case the
application has many (over a hundred) modules, and the communication link has a non-negligible
latency. This functionality is accessed by ProcessGdbRemote::PrefetchModuleSpecs(), which does
the caching. GetModuleSpecs() is modified to first consult the cache before asking the remote
stub. PrefetchModuleSpecs is currently only called from POSIX-DYLD dynamic loader plugin, after
it reads the list of modules from the inferior memory, but other uses are possible.
This decreases the attach time to an android application by about 40%.
Reviewers: clayborg
Subscribers: tberghammer, lldb-commits, danalbert
Differential Revision: https://reviews.llvm.org/D24236
llvm-svn: 280919
mode in lldb works. I've been discussing this with Jim Ingham,
Greg Clayton, and Kate Stone for the past week or two.
Previously lldb would print three source lines (centered on the
line table entry line for the current line) followed by the assembly.
It would print the context information (module`function + offset)
before those three lines of source.
Now lldb will print up to two lines before/after the line table
entry. It prints two '*' characters for the line table line to
make it clear what line is showing assembly. There is one line of
whitespace before/after the source lines so the separation between
source & assembly is clearer. I don't print the context line
(module`function + offset). I stop printing context lines if it's
a different line table entry, or if it's a source line I've already
printed as context to another source line. If I have two line table
entries one after another for the same source line (I get these often
with clang - with different column information in them), I only print
the source line once.
I'm also using the target.process.thread.step-avoid-regexp setting
(which keeps you from stepping into STL functions that have been inlined
into your own code) and avoid printing any source lines from functions
that match that regexp.
When lldb disassembles into a new function, it will try to find the
declaration line # for the function and print all of the source lines
between the decl and the first line table entry (usually a { curly brace)
so we have a good chance of including the arguments, at least with the
debug info emitted by clang.
Finally, the # of source lines of context to show has been separated
from whether we're doing mixed source & assembly or not. Previously
specifying 0 lines of context would turn off mixed source & assembly.
I think there's room for improvement, and maybe some bugs I haven't
found yet, but it's in good enough shape to upstream and iterate at
this point.
I'm not sure how best to indicate which source line is the actual line
table # versus context lines. I'm using '**' right now. Both Kate
and Greg had the initial idea to reuse '->' (normally used to indicate
"currently executing source line") - I tried it but I wasn't thrilled,
I'm too used to the established meaning of ->.
Greg had the interesting idea of avoiding context source lines only
in two line table entries in the same source file. So we'd print
two lines before & after a source line, and then the next line table
entry (if it was on the next source line after those two context lines)
we'd display only the following two lines -- the previous two had just
been printed. If an inline source line was printed between these two,
though, we'd print the context lines for both of them. It's an
interesting idea, and I want to see how it works with both -O0 and -O3
codegen where we have different amounts of inlining.
<rdar://problem/27961419>
llvm-svn: 280906
macro, so writing ::dispatch_release did not work as expected.
Remove the global anon namespace :: designation; the header will
get us the correct declaration.
llvm-svn: 280903
Function::GetStartLineSourceInfo before we try to
return the start line information about a function;
this function requires it to have been initialized.
llvm-svn: 280902
Most of these issues arose as a result of header re-ordering, but
it turned up a real bug, which is that MSVC doesn't support
__attribute__((packed)) or __attribute__((aligned)). This was
working before because there's a Windows header that #defines
__attribute__(x) to nothing. We should fix this by removing
that #define entirely, and dealing with the fallout separately
which may turn up even more bugs.
I fixed this by replacing them with the corresponding LLVM
macros which understand how to do these operations on all the
different compilers.
llvm-svn: 280757
*** to conform to clang-format’s LLVM style. This kind of mass change has
*** two obvious implications:
Firstly, merging this particular commit into a downstream fork may be a huge
effort. Alternatively, it may be worth merging all changes up to this commit,
performing the same reformatting operation locally, and then discarding the
merge for this particular commit. The commands used to accomplish this
reformatting were as follows (with current working directory as the root of
the repository):
find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} +
find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ;
The version of clang-format used was 3.9.0, and autopep8 was 1.2.4.
Secondly, “blame” style tools will generally point to this commit instead of
a meaningful prior commit. There are alternatives available that will attempt
to look through this change and find the appropriate prior commit. YMMV.
llvm-svn: 280751
MSVC emits an error when one uses a const variable in a lambda without
capturing it.
gcc and clang don't emit an error in this scenario.
llvm-svn: 280707
This reverts commit rL280668 because the register tests fail on i386
Linux.
I investigated a little bit what causes the failure - there are missing
registers when running 'register read -a'.
This is the output I got at the bottom:
"""
...
Memory Protection Extensions:
bnd0 = {0x0000000000000000 0x0000000000000000}
bnd1 = {0x0000000000000000 0x0000000000000000}
bnd2 = {0x0000000000000000 0x0000000000000000}
bnd3 = {0x0000000000000000 0x0000000000000000}
unknown:
2 registers were unavailable.
"""
Also looking at the packets exchanged between the client and server:
"""
...
history[308] tid=0x7338 < 19> send packet: $qRegisterInfo4a#d7
history[309] tid=0x7338 < 130> read packet:
$name:bnd0;bitsize:128;offset:1032;encoding:vector;format:vector-uint64;set:Memory
Protection Extensions;ehframe:101;dwarf:101;#48
history[310] tid=0x7338 < 19> send packet: $qRegisterInfo4b#d8
history[311] tid=0x7338 < 130> read packet:
$name:bnd1;bitsize:128;offset:1048;encoding:vector;format:vector-uint64;set:Memory
Protection Extensions;ehframe:102;dwarf:102;#52
history[312] tid=0x7338 < 19> send packet: $qRegisterInfo4c#d9
history[313] tid=0x7338 < 130> read packet:
$name:bnd2;bitsize:128;offset:1064;encoding:vector;format:vector-uint64;set:Memory
Protection Extensions;ehframe:103;dwarf:103;#53
history[314] tid=0x7338 < 19> send packet: $qRegisterInfo4d#da
history[315] tid=0x7338 < 130> read packet:
$name:bnd3;bitsize:128;offset:1080;encoding:vector;format:vector-uint64;set:Memory
Protection Extensions;ehframe:104;dwarf:104;#54
history[316] tid=0x7338 < 19> send packet: $qRegisterInfo4e#db
history[317] tid=0x7338 < 76> read packet:
$name:bndcfgu;bitsize:64;offset:1096;encoding:vector;format:vector-uint8;#99
history[318] tid=0x7338 < 19> send packet: $qRegisterInfo4f#dc
history[319] tid=0x7338 < 78> read packet:
$name:bndstatus;bitsize:64;offset:1104;encoding:vector;format:vector-uint8;#8e
...
"""
The bndcfgu and bndstatus registers don't have the 'Memory Protections
Extension' set. I looked at the code and it seems that that is set
correctly.
So I'm not sure what's the problem or where does it come from.
Also there is a second failure related to something like this in the
tests:
"""
registerSet.GetName().lower()
"""
For some reason the registerSet.GetName() returns None.
llvm-svn: 280703
