Page MenuHomePhabricator

clayborg (Greg Clayton)
User

Projects

User does not belong to any projects.

User Details

User Since
Sep 23 2014, 10:11 AM (376 w, 1 d)

Recent Activity

Today

clayborg updated the summary of D115324: Added the ability to cache the finalized symbol tables subsequent debug sessions to start faster..
Wed, Dec 8, 12:28 AM · Restricted Project
clayborg retitled D115324: Added the ability to cache the finalized symbol tables subsequent debug sessions to start faster. from Added the ability to cache the finalized symbol tables subsequent debug sessions to start faster. This is an updated version of the https://reviews.llvm.org/D113789 patch with the following changes: - We no longer modify modification times of the... to Added the ability to cache the finalized symbol tables subsequent debug sessions to start faster..
Wed, Dec 8, 12:28 AM · Restricted Project
clayborg requested review of D115324: Added the ability to cache the finalized symbol tables subsequent debug sessions to start faster..
Wed, Dec 8, 12:27 AM · Restricted Project

Yesterday

clayborg added a comment to D115073: Modify DataEncoder to be able to encode data in an object owned buffer..

Another fix for buildbots. Don't use llvm::ArrayRef to refer to data, store in std::vector<>. In release builds this will fail.

Tue, Dec 7, 12:21 PM · Restricted Project
clayborg committed rG220854a47bdc: Fix buildbots after https://reviews.llvm.org/D115073. (authored by clayborg).
Fix buildbots after https://reviews.llvm.org/D115073.
Tue, Dec 7, 12:19 PM
clayborg added a comment to D115073: Modify DataEncoder to be able to encode data in an object owned buffer..

Fixed a buildbot issue for linux with:

Tue, Dec 7, 12:04 PM · Restricted Project
clayborg committed rGcfe5d768be95: Fix buildbot after https://reviews.llvm.org/D115073. (authored by clayborg).
Fix buildbot after https://reviews.llvm.org/D115073.
Tue, Dec 7, 12:04 PM
clayborg committed rG244258e35acc: Modify DataEncoder to be able to encode data in an object owned buffer. (authored by clayborg).
Modify DataEncoder to be able to encode data in an object owned buffer.
Tue, Dec 7, 9:45 AM
clayborg closed D115073: Modify DataEncoder to be able to encode data in an object owned buffer..
Tue, Dec 7, 9:45 AM · Restricted Project

Mon, Dec 6

clayborg updated the diff for D115073: Modify DataEncoder to be able to encode data in an object owned buffer..

More documentation fixed for DataEncoder.

Mon, Dec 6, 2:41 PM · Restricted Project
clayborg updated the diff for D115073: Modify DataEncoder to be able to encode data in an object owned buffer..

Update the headerdoc and fixed some of the comments that were out of date or left over from the inital copy from DataExtractor.

Mon, Dec 6, 2:33 PM · Restricted Project
clayborg updated the diff for D115073: Modify DataEncoder to be able to encode data in an object owned buffer..

Updated to make DataEncoder always copy any data and own the buffer.

Mon, Dec 6, 2:09 PM · Restricted Project
clayborg added a comment to D115073: Modify DataEncoder to be able to encode data in an object owned buffer..

I don't think we actually disagree here. I'm aware of your use case (let's call it "dynamic mode") for appending to a buffer. I agree it's useful and I don't want to change that. What I want to remove is the other mode (non-dynamic). Presently, this is the only mode, but we're not actually making a good use of it. All of the existing use cases can be implemented with a "dynamic" buffer. And the code would be much simpler since there is only one mode to support -- one in which the data encoder owns the buffer it is writing to and can resize it at will.

Mon, Dec 6, 12:42 PM · Restricted Project
clayborg added a comment to D113650: [lldb] fix -print-script-interpreter-info on windows.

I can't build on macOS now. I checked out the source code and tried to do:

cmake -G Ninja -DCMAKE_BUILD_TYPE:STRING=Debug -DLLVM_ENABLE_ASSERTIONS:BOOL=TRUE -DLLVM_ENABLE_PROJECTS='clang;libcxx;libcxxabi;lldb' -DLLDB_BUILD_FRAMEWORK:BOOL=TRUE -DLLDB_USE_SYSTEM_DEBUGSERVER=ON -DLLDB_EDITLINE_USE_WCHAR=0 -DLLDB_ENABLE_LIBEDIT:BOOL=TRUE -DLLDB_ENABLE_CURSES:BOOL=TRUE -DLLDB_ENABLE_PYTHON:BOOL=TRUE -DLLDB_ENABLE_LIBXML2:BOOL=TRUE -DLLDB_ENABLE_LUA:BOOL=FALSE ../llvm-project/llvm

Random drive-by comment - any particular reason you compile without WCHAR support in libedit? I have a patch that removes the conditional support from our Editline class (actually it was committed and had to be reverted :P). But I was under the impression that nobody was using the non-WCHAR support anymore. Thanks.

Mon, Dec 6, 11:04 AM · Restricted Project
clayborg added inline comments to D115073: Modify DataEncoder to be able to encode data in an object owned buffer..
Mon, Dec 6, 11:02 AM · Restricted Project
clayborg added a comment to D115073: Modify DataEncoder to be able to encode data in an object owned buffer..

It seems to me that the DataEncoder class is a lot more complicated than what is necessary for our existing use cases. All of them involve creating a new buffer (either empty, or with some pre-existing content), modifying it, and passing it on. A lot of the DataEncoder complexity (IsDynamic, UpdateMemberVariables, ...) stems from the fact that it wants to support writing into unowned buffers, functionality that we don't even use.

Mon, Dec 6, 11:00 AM · Restricted Project

Fri, Dec 3

clayborg updated the diff for D115073: Modify DataEncoder to be able to encode data in an object owned buffer..

Fixed "DataEncoder::Append*" methods so they return false correctly when used on caller owned buffer objects.

Fri, Dec 3, 4:16 PM · Restricted Project
clayborg updated the diff for D115073: Modify DataEncoder to be able to encode data in an object owned buffer..

Update headerdoc comments and enable clang-format.

Fri, Dec 3, 3:59 PM · Restricted Project
clayborg requested review of D115073: Modify DataEncoder to be able to encode data in an object owned buffer..
Fri, Dec 3, 12:40 PM · Restricted Project
clayborg updated subscribers of D114288: [NFC] Refactor symbol table parsing..

Thanks for doing that! I was able to successfully run the test on linux, and then I added extra context to the stop. It seems that the two breakpoints are set correctly, but the second breakpoint is not hit and the program exits. So all is good from the symbol table changes as far as I have been able to tell since both breakpoints were set. Below is the extra output that shows the first breakpoint was hit, and then we continue and don't hit the second breakpoint, but we do exit with the correct exit status of 12, so the program isn't crashing. In the lines below we now can see after the "continue" command, that is just exits with the expect statu of 12 (which is argc == 1 and it multiplies it by 3 and then by 4). I am happy to help look at this. If you can send a copy of the arm "minidebuginfo-set-and-hit-breakpoint.test.tmp.binary" binary I might be able to see what is going on.

Fri, Dec 3, 9:19 AM · Restricted Project

Thu, Dec 2

clayborg added a comment to D113650: [lldb] fix -print-script-interpreter-info on windows.
Thu, Dec 2, 8:02 PM · Restricted Project
clayborg added inline comments to D114973: [lldb] add fallback for LLDB_PYTHON_RELATIVE_PATH.
Thu, Dec 2, 8:01 PM · Restricted Project
clayborg accepted D114973: [lldb] add fallback for LLDB_PYTHON_RELATIVE_PATH.

Yep, fixes it for me! Thanks!!

Thu, Dec 2, 8:00 PM · Restricted Project
clayborg added a comment to D113650: [lldb] fix -print-script-interpreter-info on windows.

I am not cross compiling in this case.

Thu, Dec 2, 5:29 PM · Restricted Project
clayborg added a comment to D113650: [lldb] fix -print-script-interpreter-info on windows.

if I try to manually set the python3 executable with:

-DPYTHON_EXECUTABLE=/Applications/Xcode.app/Contents/Developer/usr/bin/python3

I get the following error:

[cmake] CMake Error at /Users/gclayton/Documents/src/lldb/clean/llvm-project/lldb/CMakeLists.txt:53 (message):
[cmake]   Crosscompiling LLDB with Python requires manually setting
[cmake]   LLDB_PYTHON_RELATIVE_PATH.
Thu, Dec 2, 5:29 PM · Restricted Project
clayborg added a comment to D113650: [lldb] fix -print-script-interpreter-info on windows.

I can't build on macOS now. I checked out the source code and tried to do:

Thu, Dec 2, 5:27 PM · Restricted Project
clayborg added a comment to D114288: [NFC] Refactor symbol table parsing..

I will check this out on linux. Any reason why I did not get a message to my email that this was failing?

Thu, Dec 2, 3:49 PM · Restricted Project
clayborg committed rG266a66c915cb: Include extra input contents on this test so we can see why lldb-arm-ubuntu… (authored by clayborg).
Include extra input contents on this test so we can see why lldb-arm-ubuntu…
Thu, Dec 2, 3:49 PM

Wed, Dec 1

clayborg added a comment to D114288: [NFC] Refactor symbol table parsing..
Wed, Dec 1, 12:37 PM · Restricted Project

Tue, Nov 30

clayborg added inline comments to D114668: [lldb][NFC] Move generic DWARFASTParser code out of Clang-specific code.
Tue, Nov 30, 2:20 PM · Restricted Project
clayborg committed rG7e6df41f655e: [NFC] Refactor symbol table parsing. (authored by clayborg).
[NFC] Refactor symbol table parsing.
Tue, Nov 30, 1:55 PM
clayborg closed D114288: [NFC] Refactor symbol table parsing..
Tue, Nov 30, 1:54 PM · Restricted Project

Mon, Nov 29

clayborg updated the diff for D114288: [NFC] Refactor symbol table parsing..

Let the call_once protect the ObjectFile::m_symtab_up as suggested.

Mon, Nov 29, 12:39 PM · Restricted Project

Wed, Nov 24

clayborg added a comment to D114288: [NFC] Refactor symbol table parsing..

I don't believe this solution is correct.

How did this work before? Is it because ObjectFileELF::GetSymtab contained the same (incorrect) unique_ptr pattern?

Wed, Nov 24, 6:18 PM · Restricted Project

Mon, Nov 22

clayborg accepted D112147: [lldb] Fix lookup for global constants in namespaces.

LGTM!

Mon, Nov 22, 10:54 AM · Restricted Project

Fri, Nov 19

clayborg added a comment to D113965: [NFC] Refactor symbol table parsing..

I resubmitted with a fix in https://reviews.llvm.org/D114288

Fri, Nov 19, 2:42 PM · Restricted Project
clayborg requested review of D114288: [NFC] Refactor symbol table parsing..
Fri, Nov 19, 2:41 PM · Restricted Project

Thu, Nov 18

clayborg added a comment to D111899: LLDB tests modification for hardware breakpoints.

Never mind, it seems to be fixed. Although the problem I mentioned is still true where some test cases might set "self.target = debugger.CreateTarget(...)" and if those test cases try to use the check_breakpoint function. See suggested code edit for a potential fix.

Thu, Nov 18, 9:21 PM · Restricted Project
clayborg added a comment to D111899: LLDB tests modification for hardware breakpoints.

FYI, this broke all the TestObjCNewSyntax* tests. I *think* I've fixed them.

Thu, Nov 18, 8:44 PM · Restricted Project
clayborg added a comment to D111899: LLDB tests modification for hardware breakpoints.

The right fix IMHO is to rename the function in lldbtest.py from "def target(self):" to "def selected_target(self):" and then find all call sites and fix them.

Thu, Nov 18, 8:37 PM · Restricted Project
clayborg added a comment to D111899: LLDB tests modification for hardware breakpoints.

This change causes many test suite errors due to inline comment. Please fix ASAP

Thu, Nov 18, 8:34 PM · Restricted Project
clayborg accepted D114111: Remove a useless temporary of a base class type..
Thu, Nov 18, 11:49 AM · Restricted Project

Wed, Nov 17

clayborg added a comment to D113965: [NFC] Refactor symbol table parsing..

I had to revert this. There is a deadlock in:

Wed, Nov 17, 10:10 PM · Restricted Project
clayborg accepted D114123: [NFC][lldb] Inclusive language: remove instances of master from comments in lldb.
Wed, Nov 17, 9:39 PM · Restricted Project
clayborg added a reverting change for rG951b107eedab: [NFC] Refactor symbol table parsing.: rGa68ccda203aa: Revert "[NFC] Refactor symbol table parsing.".
Wed, Nov 17, 6:08 PM
clayborg committed rGa68ccda203aa: Revert "[NFC] Refactor symbol table parsing." (authored by clayborg).
Revert "[NFC] Refactor symbol table parsing."
Wed, Nov 17, 6:08 PM
clayborg added a reverting change for D113965: [NFC] Refactor symbol table parsing.: rGa68ccda203aa: Revert "[NFC] Refactor symbol table parsing.".
Wed, Nov 17, 6:08 PM · Restricted Project
clayborg committed rG951b107eedab: [NFC] Refactor symbol table parsing. (authored by clayborg).
[NFC] Refactor symbol table parsing.
Wed, Nov 17, 3:14 PM
clayborg closed D113965: [NFC] Refactor symbol table parsing..
Wed, Nov 17, 3:14 PM · Restricted Project
clayborg requested changes to D114123: [NFC][lldb] Inclusive language: remove instances of master from comments in lldb.

Suggested different replacement strings for the comments.

Wed, Nov 17, 3:01 PM · Restricted Project
clayborg added a comment to D113498: [lldb] Constant-resolve operands to `getelementptr`.

FYI: I am not familiar enough with the expression parser and IR interpreter logic to be able to be able to give the ok here. I hope other expression parser experts will continue to give good feedback on this patch!

Wed, Nov 17, 2:58 PM · Restricted Project

Tue, Nov 16

clayborg added a comment to D82367: [ObjectYAML][ELF] Add support for emitting the .debug_gnu_pubnames/pubtypes sections..

Is ".debug_gnu_pubtypes" different and/or better than the old ".debug_pubtypes" in terms of contents? AFAIK all debuggers completely ignore these sections as they don't contain all types (only public types). I did a quick web search for ".debug_gnu_pubtypes" and didn't find any docs or anything documenting this format.

My general understanding is that GCC/GDB folks implemented .debug_gnu_pubnames(/types) because of the lack of guarantees in debug_pubnames(/types) - GCC does consume/rely on these sections (& gold can produce .gdb_index from these gnu_pub* sections - which is /necessary/ for correctness of gdb when using Split DWARF, in fact).

I'm guessing like lots of stuff, it's probably basically defined by the agreement between GCC and GDB - and Clang/LLVM just tries to implement gnu_pub* to be as compatible as possible with that.

Was there any documentation on this where the contents of this new format are detailed?

Not that I know of.

Sounds promising and I would love to have LLDB to not have to manually index DWARF on all linux/android targets if at all possible.

Presumably LLDB should probably be looking at the newer .debug_names format that's been standardized/documented, and derived from the apple names accelerator tables.

Tue, Nov 16, 9:45 AM · Restricted Project

Mon, Nov 15

clayborg requested review of D113965: [NFC] Refactor symbol table parsing..
Mon, Nov 15, 10:50 PM · Restricted Project
clayborg added a comment to D113810: Add the stop count to "statistics dump" in each target's dictionary..

The stop id includes all the user expression stops. So the same "drive through code" could produce very different stop counts if you ran a bunch of p-s in one session but not the other. You can't do better than that at present since we only track the natural/vrs. expression stop id for the last stop. But if it mattered you could keep a separate "natural stop" counter and report that instead. You can't quite get back to the natural stops by subtracting the number of expressions, because not all expressions run the target, and some do twice (if the one-thread run times out).

I actually don't care about the number of natural user stops as the user will be aware of these stops. The info I am interested in is when a debug session has thousands of stops that auto resumed a debug session. This can happen if unix signals are used for program flow control or working around things. Android uses SIGSEGV for catching java NULL derefs and many times we will auto resume from these depending on signal settings. If a debug session is taking a long time it is nice to know. Some users might also have some python module that gets loaded and might end up setting a breakpoint with a callback that can auto resume.

IMO, the real solution for this issue is for lldb to invent (if there isn't already) a "auto-continue signals" packet, so we could tell the stub to restart from those signals w/o even telling lldb about it. Oh, but I guess you can't do that for SIGSEGV...

Mon, Nov 15, 8:43 PM · Restricted Project
clayborg committed rGdbd36e1e9f16: Add the stop count to "statistics dump" in each target's dictionary. (authored by clayborg).
Add the stop count to "statistics dump" in each target's dictionary.
Mon, Nov 15, 6:59 PM
clayborg closed D113810: Add the stop count to "statistics dump" in each target's dictionary..
Mon, Nov 15, 6:59 PM · Restricted Project
clayborg added a comment to D113789: Add the ability to cache information for a module between debugger instances..

Some perf numbers that involve loading a large iOS Application and all of its shared libraries without caching first and then with caching are found below. The "lldb-perf.py" command will start a timer, run any LLDB commands and then stop the timer and print out. Before the first run, I run "sudo purge" to purge the kernel file cache, and then I run one "cold" run with the file caches being empty. Then I run the same thing again with hot file caches. So the first run is always slower.

Mon, Nov 15, 4:52 PM · Restricted Project
clayborg added a comment to D113789: Add the ability to cache information for a module between debugger instances..

Thinking about this a bit more after Pavel's comment on if performance was improved due to mangling: we don't currently get any perf improvement from mangling/demangling. We might be able to get better performance out of this as well if we _do_ cache the "mangled/demangled" counterparts (save both strings when they are related instead of just saving the mangled string like I do in this patch) when we serialize the Mangled objects. When the objects are deserialized, they could read both strings and then no demangling would need to happen for that mangled name since it could be registers as the counterpart strings during deserialization...

Mon, Nov 15, 3:34 PM · Restricted Project
clayborg added a comment to D113789: Add the ability to cache information for a module between debugger instances..

Maybe it's good for starting a discussion, but I am surprised that we would need to cache symtab information. This is a fairly simple format that needs to be read at application runtime as well, so I am surprised that reading it from the cache is substantially faster than doing it from the object file. What is the slow part there? Is it demangling by any chance?

Mon, Nov 15, 3:22 PM · Restricted Project
clayborg added a comment to D82367: [ObjectYAML][ELF] Add support for emitting the .debug_gnu_pubnames/pubtypes sections..

Is ".debug_gnu_pubtypes" different and/or better than the old ".debug_pubtypes" in terms of contents? AFAIK all debuggers completely ignore these sections as they don't contain all types (only public types). I did a quick web search for ".debug_gnu_pubtypes" and didn't find any docs or anything documenting this format.

My general understanding is that GCC/GDB folks implemented .debug_gnu_pubnames(/types) because of the lack of guarantees in debug_pubnames(/types) - GCC does consume/rely on these sections (& gold can produce .gdb_index from these gnu_pub* sections - which is /necessary/ for correctness of gdb when using Split DWARF, in fact).

I'm guessing like lots of stuff, it's probably basically defined by the agreement between GCC and GDB - and Clang/LLVM just tries to implement gnu_pub* to be as compatible as possible with that.

Mon, Nov 15, 3:08 PM · Restricted Project
clayborg added a comment to D82367: [ObjectYAML][ELF] Add support for emitting the .debug_gnu_pubnames/pubtypes sections..

Is ".debug_gnu_pubtypes" different and/or better than the old ".debug_pubtypes" in terms of contents? AFAIK all debuggers completely ignore these sections as they don't contain all types (only public types). I did a quick web search for ".debug_gnu_pubtypes" and didn't find any docs or anything documenting this format.

Mon, Nov 15, 2:46 PM · Restricted Project
clayborg added a comment to D113810: Add the stop count to "statistics dump" in each target's dictionary..

The stop id includes all the user expression stops. So the same "drive through code" could produce very different stop counts if you ran a bunch of p-s in one session but not the other. You can't do better than that at present since we only track the natural/vrs. expression stop id for the last stop. But if it mattered you could keep a separate "natural stop" counter and report that instead. You can't quite get back to the natural stops by subtracting the number of expressions, because not all expressions run the target, and some do twice (if the one-thread run times out).

Mon, Nov 15, 11:35 AM · Restricted Project

Fri, Nov 12

clayborg added inline comments to D113789: Add the ability to cache information for a module between debugger instances..
Fri, Nov 12, 4:01 PM · Restricted Project
clayborg updated the diff for D113789: Add the ability to cache information for a module between debugger instances..

Added more comments to the encoding functions to detail how things are encoded.
Fixed error typos.
Added version to symbol table cache file so we can improve the format as time goes on and avoid loading out of data caches.

Fri, Nov 12, 4:00 PM · Restricted Project
clayborg requested review of D113810: Add the stop count to "statistics dump" in each target's dictionary..
Fri, Nov 12, 3:27 PM · Restricted Project
clayborg requested review of D113789: Add the ability to cache information for a module between debugger instances..
Fri, Nov 12, 11:54 AM · Restricted Project

Thu, Nov 11

clayborg accepted D113720: [lldb][NFC] Inclusive language: rename m_master in ASTImporterDelegate.
Thu, Nov 11, 3:32 PM · Restricted Project
clayborg accepted D113687: [lldb][NFC] Inclusive language: replace master/slave names for ptys.
Thu, Nov 11, 11:38 AM · Restricted Project
clayborg added a comment to D113521: Allow lldb to launch a remote executable when there isn't a local copy.

I'm good with this to get things started. Pavel?

Thu, Nov 11, 11:36 AM · Restricted Project

Wed, Nov 10

clayborg added a comment to D113521: Allow lldb to launch a remote executable when there isn't a local copy.

I have two high-level questions about this:

  • what should be the relative priority of executable ModuleSP vs the launch info? IIUC, in the current implementation the module takes precedence, but it seems to me it would be more natural if the launch info came out on top. One of the reasons I'm thinking about this is because you currently cannot re-run executables that use exec(2) (I mean, you can, but it will rarely produce the desired results). This happens because we use the post-exec executable, but the rest of the launch info refers to the main one. If the executable module was not the primary source of truth here, then maybe the we could somehow use this mechanism to improve the exec story as well (by storing the original executable in the launch info or something).

As you point out indirectly above, there are really three entities in play here. There's the Target's ExecutableModule; there's the GetExecutableFile in a user-provided ProcessLaunchInfo passed to SBTarget::Launch, for instance; and there's the ProcessLaunchInfo that's stored in the TargetProperties held by the target.
So we need to decide what it means when these three entities differ.

Shouldn't the target;s launch info get a full copy of the user-provided ProcessLaunchInfo upon launch? If that is the case, then we always can refer to the target's launch info as the truth as far as ProcessLaunchInfo goes? Then the only question we have is what to do if the target has a module

Wed, Nov 10, 3:44 PM · Restricted Project
clayborg accepted D113487: [lldb] Refactor Platform::ResolveExecutable.
Wed, Nov 10, 3:06 PM · Restricted Project

Tue, Nov 9

clayborg abandoned D110804: Add a new command "target metrics"..

This was submitted as a series of patches that updated "statistics dump" to emit JSON:

Tue, Nov 9, 3:24 PM · Restricted Project
clayborg added a comment to D113487: [lldb] Refactor Platform::ResolveExecutable.

LGTM. I will ok soon if no one else chimes in!

Tue, Nov 9, 3:22 PM · Restricted Project
clayborg added a comment to D113400: [lldb-vscode] Add presentation hints for scopes.

nice!

Tue, Nov 9, 3:17 PM · Restricted Project
clayborg added inline comments to D112147: [lldb] Fix lookup for global constants in namespaces.
Tue, Nov 9, 3:14 PM · Restricted Project

Mon, Nov 8

clayborg added a comment to D108261: [DebugInfo] Fix end_sequence of debug_line in LTO Object.

Any progress on this? This causes serious debugging issues.

Mon, Nov 8, 9:33 PM · Restricted Project

Nov 1 2021

clayborg added inline comments to D112931: Fix mixed disassembly showing source lines for "line 0".
Nov 1 2021, 1:31 PM · Restricted Project
clayborg added a comment to D112931: Fix mixed disassembly showing source lines for "line 0".

LGTM. This is in Jason's function so I will let him give the final ok.

Nov 1 2021, 1:30 PM · Restricted Project

Oct 29 2021

clayborg accepted D112834: [lldb-vscode] Fix coredump load source mapping for first file.

This is how launch does it as well, so LGTM.

Oct 29 2021, 2:47 PM · Restricted Project

Oct 28 2021

clayborg accepted D112747: Restore process events after a launch that stopped at the entry point.

ok, lgtm

Oct 28 2021, 4:30 PM · Restricted Project
clayborg added inline comments to D112747: Restore process events after a launch that stopped at the entry point.
Oct 28 2021, 4:18 PM · Restricted Project
clayborg abandoned D112691: Include target settings in "statistics dump" output..
Oct 28 2021, 4:11 PM · Restricted Project
clayborg added a comment to D112691: Include target settings in "statistics dump" output..

In D112691#3095010, @jingham wrote:
I can see wanting to dump statistics at various points in the running of a process, maybe triggered by breakpoints, for instance. In that case I wouldn't want to dump the settings data - if it is indeed redundant (see above) every time. Having the settings as a separate emission would make that possible. And just like we add gdb-remote as a convenience, it would be fine to have some low level commands that you can reassemble and then a portmanteau command that generates a "good for most purposes" report.

Oct 28 2021, 4:10 PM · Restricted Project
clayborg added a comment to D112691: Include target settings in "statistics dump" output..

Do you care about the history of these settings? After all, the problem might arise because someone set a setting then unset it. Your statistics approach wouldn't catch that. If you are really trying to build an architecture where we can track this sort of problem down, then you might need more of a history approach, where the settings and certain other changes in the state of the debugger mark epochs, and you aggregate data into those epochs?

Oct 28 2021, 3:18 PM · Restricted Project
clayborg added a comment to D112691: Include target settings in "statistics dump" output..

I understand the need for something like this to make some of the statistics more meaningful, but this is stretching the notion of statistics. Conceptually, this is approaching something like a dump of the debugger for issue/performance analysis. I think that idea is really exciting, and from that perspective there's a lot more useful information we could add to it. Long term, I can see this output be something that we ask users to include in every bug report.

Oct 28 2021, 3:07 PM · Restricted Project

Oct 27 2021

clayborg requested review of D112691: Include target settings in "statistics dump" output..
Oct 27 2021, 11:30 PM · Restricted Project
clayborg committed rG130055647922: Add unix signal hit counts to the target statistics. (authored by clayborg).
Add unix signal hit counts to the target statistics.
Oct 27 2021, 10:31 PM
clayborg closed D112683: Add unix signal hit counts to the target statistics..
Oct 27 2021, 10:31 PM · Restricted Project
clayborg requested review of D112683: Add unix signal hit counts to the target statistics..
Oct 27 2021, 6:35 PM · Restricted Project
clayborg added a comment to D112587: Add breakpoint resolving stats to each target..

Note, the breakpoint serialization for breakpoints only serializes the filter/resolver and the breakpoint specific options. It doesn't do anything with locations or their options. After all, you when you go to reset a breakpoint in another session (which is what this serialization is for) you have no way of knowing what locations you are going to find.

Oct 27 2021, 5:50 PM · Restricted Project
clayborg accepted D112677: Remove unused ValueObjectDynamicValue::SetOwningSP & backing ivar.

I am sure you have checked the Swift codebase as well for any uses. If so LGTM.

Oct 27 2021, 5:02 PM · Restricted Project
clayborg committed rGfb2549683260: Add breakpoint resolving stats to each target. (authored by clayborg).
Add breakpoint resolving stats to each target.
Oct 27 2021, 4:50 PM
clayborg closed D112587: Add breakpoint resolving stats to each target..
Oct 27 2021, 4:50 PM · Restricted Project
clayborg added a comment to D110827: [LLDB] Provide target specific directories to libclang.

Looks good to me, but the expression parser isn't my main area of expertise. I would like to see someone with more knowledge in the expression parser to make the final ok. Raphael?

Oct 27 2021, 2:56 PM · Restricted Project
clayborg added inline comments to D112587: Add breakpoint resolving stats to each target..
Oct 27 2021, 2:50 PM · Restricted Project
clayborg updated the diff for D112587: Add breakpoint resolving stats to each target..

Changes in this version:

  • If we fail to get "details" from the structured data, we put the error string into the "details" dictionary with the error string.
  • Added "numLocations" (int64_t) and "numResolvedLocations" (int64_t) and "internal" (bool) into each breakpoint's stats.
  • Include the internal breakpoints in the "breakpoints" so we are tracking all breakpoints that are being set.
  • Removed the top level "names" field because it is already contained in the "details".
Oct 27 2021, 2:46 PM · Restricted Project

Oct 26 2021

clayborg requested review of D112587: Add breakpoint resolving stats to each target..
Oct 26 2021, 5:54 PM · Restricted Project
clayborg committed rG2887d9fd864c: Add new key/value pairs to the module statistics for "statistics dump". (authored by clayborg).
Add new key/value pairs to the module statistics for "statistics dump".
Oct 26 2021, 3:09 PM
clayborg closed D112501: Add new key/value pairs to the module statistics for "statistics dump"..
Oct 26 2021, 3:09 PM · Restricted Project

Oct 25 2021

clayborg updated the diff for D112501: Add new key/value pairs to the module statistics for "statistics dump"..

Added newlines to files that needed them at the end of the file.

Oct 25 2021, 6:14 PM · Restricted Project