| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[lldb][trace] Add a basic function call dump [2] - Implement the reconstruction algorithm This diff implements the reconstruction algorithm for the call tree and add tests. See TraceDumper.h for documentation and explanations. One important detail is that the tree objects are in TraceDumper, even though Trace.h is a better home. I'm leaving that as future work. Another detail is that this code is as slow as dumping the entire symolicated trace, which is not that bad tbh. The reason is that we use symbols throughout the algorithm and we are not being careful about memory and speed. This is also another area for future improvement. Lastly, I made sure that incomplete traces work, i.e. you start tracing very deep in the stack or failures randomly appear in the trace. Differential Revision: https://reviews.llvm.org/D135917 | 3 年前 | |
[trace][intel pt] Support a new kernel section in LLDB’s trace bundle schema Add a new "kernel" section with following schema. "kernel": { "loadAddress"?: decimal | hex string | string decimal # This is optional. If it's not specified, use default address 0xffffffff81000000. "file": string # path to the kernel image } Here's more details of the diff: - If "kernel" section exist, it means current tracing mode is //KernelMode//. - If tracing mode is //KernelMode//, the "processes" section must be empty and the "kernel" and "cpus" section must be provided. This is tested with TestTraceLoad. - "kernel" section is parsed and turned into a new process with a single module which is the kernel image. The kernel process has N fake threads, one for each cpu. Reviewed By: wallace Differential Revision: https://reviews.llvm.org/D130805 | 3 年前 | |
[trace][intelpt] Support system-wide tracing [21] - Support long numbers in JSON llvm's JSON parser supports 64 bit integers, but other tools like the ones written in JS don't support numbers that big, so we need to represent these possibly big numbers as a string. This diff uses that to represent addresses and tsc zero. The former is printed in hex for and the latter in decimal string form. The schema was updated mentioning that. Besides that, I fixed some remaining issues and now all test pass. Before I wasn't running all tests because for some reason my computer reverted perf_paranoid to 1. Differential Revision: https://reviews.llvm.org/D127819 | 4 年前 | |
[trace][intelpt] Support system-wide tracing [20] - Rename some fields in the schema As discusses offline with @jj10305, we are updating some naming used throughout the code, specially in the json schema - traceBuffer -> iptTrace - core -> cpu Differential Revision: https://reviews.llvm.org/D127817 | 4 年前 | |
[trace][intelpt] Support system-wide tracing [20] - Rename some fields in the schema As discusses offline with @jj10305, we are updating some naming used throughout the code, specially in the json schema - traceBuffer -> iptTrace - core -> cpu Differential Revision: https://reviews.llvm.org/D127817 | 4 年前 | |
[lldb][test] Remove duplicate testcase names in API test-suite (#97043) In one of my recent PRs I mistakenly had two test-cases with the same name, preventing one of them to run. Since it's an easy mistake to make (e.g., copy pasting existing test-cases), I ran following sanity-check script over lldb/test/API, which found couple of tests which were losing coverage because of this (or in some cases simply had duplicate tests): import ast import sys filename = sys.argv[1] print(f'Checking {filename}...') tree = ast.parse(open(filename, 'r').read()) for node in ast.walk(tree): if not isinstance(node, ast.ClassDef): continue func_names = [] for child in ast.iter_child_nodes(node): if isinstance(child, ast.FunctionDef): func_names.append(child.name) seen_func_names = set() duplicate_func_names = [] for name in func_names: if name in seen_func_names: duplicate_func_names.append(name) else: seen_func_names.add(name) if len(duplicate_func_names) != 0: print(f'Multiple func names found:\n\t{duplicate_func_names}\n\tclass {node.name}\n\tfile: {filename}') This patch fixes these cases. | 2 年前 | |
[NFC][Py Reformat] Reformat python files in lldb This is an ongoing series of commits that are reformatting our Python code. Reformatting is done with black (23.1.0). If you end up having problems merging this commit because you have made changes to a python file, the best way to handle that is to run git checkout --ours <yourfile> and then reformat it with black. RFC: https://discourse.llvm.org/t/rfc-document-and-standardize-python-code-style Differential revision: https://reviews.llvm.org/D151460 | 3 年前 | |
| 2 年前 | ||
[NFC][Py Reformat] Reformat python files in lldb This is an ongoing series of commits that are reformatting our Python code. Reformatting is done with black (23.1.0). If you end up having problems merging this commit because you have made changes to a python file, the best way to handle that is to run git checkout --ours <yourfile> and then reformat it with black. RFC: https://discourse.llvm.org/t/rfc-document-and-standardize-python-code-style Differential revision: https://reviews.llvm.org/D151460 | 3 年前 | |
[NFC][Py Reformat] Reformat python files in lldb This is an ongoing series of commits that are reformatting our Python code. Reformatting is done with black (23.1.0). If you end up having problems merging this commit because you have made changes to a python file, the best way to handle that is to run git checkout --ours <yourfile> and then reformat it with black. RFC: https://discourse.llvm.org/t/rfc-document-and-standardize-python-code-style Differential revision: https://reviews.llvm.org/D151460 | 3 年前 | |
[lldb][test] Modernize asserts (#82503) This uses [teyit](https://pypi.org/project/teyit/) to modernize asserts, as recommended by the [unittest release notes](https://docs.python.org/3.12/whatsnew/3.12.html#id3). For example, assertTrue(a == b) is replaced with assertEqual(a, b). This produces better error messages, e.g. error: unexpectedly found 1 and 2 to be different instead of error: False. | 2 年前 | |
| 2 年前 | ||
[lldb][test] Modernize assertEqual(value, bool) (#82526) Any time we see the pattern assertEqual(value, bool), we can replace that with assert<bool>(value). Likewise for assertNotEqual. Technically this relaxes the test a bit, as we may want to make sure value is either True or False, and not something that implicitly converts to a bool. For example, assertEqual("foo", True) will fail, but assertTrue("foo") will not. In most cases, this distinction is not important. There are two such places that this patch does **not** transform, since it seems intentional that we want the result to be a bool: * https://github.com/llvm/llvm-project/blob/5daf2001a1e4d71ce1273a1e7e31cf6e6ac37c10/lldb/test/API/python_api/sbstructureddata/TestStructuredDataAPI.py#L90 * https://github.com/llvm/llvm-project/blob/5daf2001a1e4d71ce1273a1e7e31cf6e6ac37c10/lldb/test/API/commands/settings/TestSettings.py#L940 Followup to 9c2468821ec51defd09c246fea4a47886fff8c01. I patched teyit with a visit_assertEqual node handler to generate this. | 2 年前 | |
[NFC][Py Reformat] Reformat python files in lldb This is an ongoing series of commits that are reformatting our Python code. Reformatting is done with black (23.1.0). If you end up having problems merging this commit because you have made changes to a python file, the best way to handle that is to run git checkout --ours <yourfile> and then reformat it with black. RFC: https://discourse.llvm.org/t/rfc-document-and-standardize-python-code-style Differential revision: https://reviews.llvm.org/D151460 | 3 年前 | |
[NFC][Py Reformat] Reformat python files in lldb This is an ongoing series of commits that are reformatting our Python code. Reformatting is done with black (23.1.0). If you end up having problems merging this commit because you have made changes to a python file, the best way to handle that is to run git checkout --ours <yourfile> and then reformat it with black. RFC: https://discourse.llvm.org/t/rfc-document-and-standardize-python-code-style Differential revision: https://reviews.llvm.org/D151460 | 3 年前 | |
[NFC][Py Reformat] Reformat python files in lldb This is an ongoing series of commits that are reformatting our Python code. Reformatting is done with black (23.1.0). If you end up having problems merging this commit because you have made changes to a python file, the best way to handle that is to run git checkout --ours <yourfile> and then reformat it with black. RFC: https://discourse.llvm.org/t/rfc-document-and-standardize-python-code-style Differential revision: https://reviews.llvm.org/D151460 | 3 年前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 3 年前 | ||
| 3 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 2 年前 | ||
| 3 年前 | ||
| 2 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 |