Page MenuHomePhabricator
Feed Advanced Search

Today

labath added a comment to D77047: AArch64 SVE register infos and ptrace support.

There is no physical hardware currently available to test SVE and we make use of QEMU for the purpose of testing this feature.

Wed, Apr 1, 5:30 AM
labath added a comment to D72251: [RFC] Support SVE registers access on AArch64 Linux.

Thanks for splitting this up.

Wed, Apr 1, 5:30 AM · Restricted Project
labath added a comment to D77045: Add invalidate list to primary regs in arm64 register infos.

This sounds like it could use a test case.

Wed, Apr 1, 5:30 AM
labath added a comment to D77044: Extend max register size to accommodate AArch64 SVE vector regs.

Sounds fairly noncontroversial. I don't think we have too many of these objects floating around, but if it turns out we do, we could switch to a SmallVector to optimize for the common case of smaller registers.

Wed, Apr 1, 5:30 AM
labath added a reviewer for D77043: Fix process gdb-remote usage of value_regs/invalidate_regs: jasonmolenda.

I am still thinking this over, but for now I have two comments. First, could you re-upload the diff with full context (e.g. git show -U9999). That would make it a lot easier to review this.
Second, would it be possible to change the meaning of the invalidate_regs and value_regs lists so that they do the right thing even in your case (instead of introducing a new number)? We already have too many numbering schemes to begin with, and introducing a new one is definitely something I'd like to avoid (in particular when the number is stored as eRegisterKindLLDB on the server side, but then becomes eRegisterKindProcessPlugin on the other end).

Wed, Apr 1, 4:58 AM
labath accepted D76729: Convert for loops to entry-based iteration.
Wed, Apr 1, 4:58 AM · Restricted Project
labath added a comment to D73206: Pass `CompileUnit *` along `DWARFDIE` for DWZ.

The internal representation of DebugNames and Apple indexes is fixed by the relevant (pseudo-)standards, so we can't really change it. The question is how to efficiently (and cleanly) convert from the internal representation to some common thing. The conversion from AppleIndex to DIERef is trivial (which is not surprising as it was the first and the overall design was optimized for that). With debug_names, the situation gets more tricky. The internal representation of debug_names uses CU-relative DIE offsets, but DIERef wants an absolute offset. That means the index has to do more work to produce the common representation. And it needs to do that for all results, even though a lot of the index users are really interested only in a single entry. With the switch to user_id_t, _all_ indexes would have to do some extra work to encode it, only for their users to have to immediately decode it back. Having a iterator/callback based api would allow us to minimize the impact of that, as it would only need to happen for the entries that are really used. And /I think/ we could make it interface returns DWARFDies directly, and each index converts to that using the most direct approach available.

Wed, Apr 1, 4:58 AM · Restricted Project
labath accepted D76806: Remove m_last_file_sp from SourceManager.

I think this is fine now. Jim, do you have any more thoughts on this patchset?

Wed, Apr 1, 3:19 AM · Restricted Project
labath added a comment to D75750: [lldb] integrate debuginfod.

The main issue is that the symbol vendors currently are ELF, macOS and WASM. Right now we have one SymbolVendor for a triple, but I can see a SymbolVendor wanting to use multiple symbol servers to get information: one for the OS binaries (debuginfod or DebugSymbols.framework at Apple) and one for the current application with company specific symbol servers. At Apple, they can download any symbols for macOS, iOS, watchOS and tvOS OSes and applications. At Facebook we can download symbols for android, linux and iOS. Linux distros might have ways to download symbols for their OS stuff, which might work along side debuginfod? Also windows has the ability to download symbols.

So it might be good to have the SymbolVendors use one or more SymbolServer plug-ins.

Wed, Apr 1, 3:18 AM · Restricted Project
labath accepted D77145: [DebugInfo] Fix reading location tables of v5 units in DWP..

looks good to me too

Wed, Apr 1, 2:50 AM · debug-info, Restricted Project
labath committed rG0ec88d031ad5: [lldb] Inherit host environment when running shell commands (authored by labath).
[lldb] Inherit host environment when running shell commands
Wed, Apr 1, 2:44 AM
labath closed D77123: [lldb] Inherit host environment when running shell commands.
Wed, Apr 1, 2:44 AM · Restricted Project
labath accepted D75929: [DebugInfo] Support DWARFv5 index sections..

Thanks for doing this. This looks fine to me. @dblaikie, @jhenderson, do you have any additional comments?

Wed, Apr 1, 2:43 AM · Restricted Project, debug-info, Restricted Project
labath accepted D77107: [intel-pt] Implement a basic test case.
Wed, Apr 1, 2:43 AM · Restricted Project
labath added a comment to D77186: [source maps] Ensure all valid source maps are added instead of failing with the first invalid one.

It seems somewhat odd for a command to return error (one of the effects of that for instance is to abort processing of batch scripts), but still perform some changes. It might be more appropriate to call those warnings. However, reporting warnings from here would require some plumbing, and the new behavior is definitely more reasonable than the old one, so I don't think this patch should be blocked on that.

Wed, Apr 1, 2:09 AM · Restricted Project
labath requested changes to D76968: [lldb-vscode] Correctly return source mapped breakpoints for setBreakpoints request.

Thanks for the updates and for writing the test. The code looks fine to me, the "request changes" is for making sure the test follows best practices and is portable.

Wed, Apr 1, 1:36 AM · Restricted Project
labath added a comment to D76471: Remap the target SDK directory to the host SDK directory.

I don't think that spreading this out over host and platform is convoluted. In fact, I was going to propose something like that myself. However, it does bring us back to the question of the "linux" sdk.

Wed, Apr 1, 1:36 AM
labath accepted D77197: [lldb] Allow expect_expr without a running target.

looks good.

Wed, Apr 1, 1:03 AM · Restricted Project
labath added a comment to D77153: [lldb/DataFormatters] Display null C++ pointers as nullptr.

It might be worth mentioning though that the title of the patch is somewhat misleading -- I believe the CXX in CXXFunctionSummaryFormat refers to the language the formatter is implemented in, not the language of the type itself. So this patch affects all types whose formatters are implemented as c++ functions, not all c++ pointers in the target program.

Wed, Apr 1, 12:30 AM · Restricted Project
labath added a comment to D77153: [lldb/DataFormatters] Display null C++ pointers as nullptr.

I haven't tested the libstdc++ part, would be great if someone could confirm this works.

Wed, Apr 1, 12:30 AM · Restricted Project

Yesterday

labath added a comment to D77108: [lldb/DWARF] Fix evaluator crash when accessing empty stack.

For the future, a clean solution would be extending the macros in Dwarf.def to list the stack effects in the definitions of the DW_OP_*, for example

// opcode, name, version, vendor, in, out
HANDLE_DW_OP(0x12, dup, 2, DWARF, 1, 2)
Tue, Mar 31, 10:33 AM · debug-info, Restricted Project
labath added a comment to D75750: [lldb] integrate debuginfod.

Making a plugin out of this sounds like a good idea to me, and I could immediately find several downstream users for it. However, it seems to me there is a great deal of overlap between this SymbolServer thingy and the existing SymbolVendor plugin (I mean, "vend" and "serve" are basically synonyms in this context). The main difference is that SymbolVendor is responsible for just finding the symbol file (in case it is not in the main executable), where as this new thing could also be used for finding the main executable too (as well as the relevant source files).

Tue, Mar 31, 3:18 AM · Restricted Project
labath added a comment to D76471: Remap the target SDK directory to the host SDK directory.

Having this in the host layer sounds good to me.

Tue, Mar 31, 2:42 AM
labath added a comment to D77123: [lldb] Inherit host environment when running shell commands.

This stems from D76835 -- when the inherit fallback on windows gets removed some tests fail bacause the can't find ls. This is used in lldbutil.wait_for_file_on_target. The inheritance was not a problem because ls is normally in the hardcoded default path, but that is not the case on windows.

Tue, Mar 31, 2:42 AM · Restricted Project
labath added a comment to D77108: [lldb/DWARF] Fix evaluator crash when accessing empty stack.
In D77108#1951997, @kwk wrote:

Most DW_OP cases check their stack, but it's quite possible that others were missed too. It might be a nice cleanup to make a function like (getMinimalStackSize(op)) and move this check up in front of the big switch. That could not handle all operators, as for some of them, the value is not statically known, but it would handle the vast majority of them.

@labath I somewhat like that the logic for each op is close to the case statement. Creating the function that you suggested would separate this check out somewhere else and you would have to look at two places. At least for code review, the current solution is much clearer to me.

Tue, Mar 31, 2:42 AM · debug-info, Restricted Project
labath created D77123: [lldb] Inherit host environment when running shell commands.
Tue, Mar 31, 2:42 AM · Restricted Project
labath added a comment to D77108: [lldb/DWARF] Fix evaluator crash when accessing empty stack.

This is obviously good! Do you think that a similar error handling bug might exist in other cases that depend top-of-stack?

Tue, Mar 31, 1:04 AM · debug-info, Restricted Project
labath added a comment to D76968: [lldb-vscode] Correctly return source mapped breakpoints for setBreakpoints request.

Looks good as long as with we have "llvm::Optional<llvm::StringRef> request_path = {}" in the arguments for a function, that "{}" will turn into llvm::None and not an empty StringRef? Unclear to me. As long as this is what is happening and as long is this coding convention is used elsewhere in llvm (using "{}" instead of "llvm::None") I am ok. Pavel?

Tue, Mar 31, 1:04 AM · Restricted Project
labath accepted D76872: [intel-pt] Fix existing support in LLDB.
Tue, Mar 31, 12:30 AM · Restricted Project
labath added a comment to D77107: [intel-pt] Implement a basic test case.

It's nice to see this code getting some use. I was starting to think we should delete it...

Tue, Mar 31, 12:30 AM · Restricted Project

Mon, Mar 30

labath committed rG37889786b040: Revert "[lldb] Fix TestSettings.test_pass_host_env_vars on windows" (authored by labath).
Revert "[lldb] Fix TestSettings.test_pass_host_env_vars on windows"
Mon, Mar 30, 8:38 AM
labath committed rG908f78f3c198: [lldb] Fix TestSettings.test_pass_host_env_vars on windows (authored by labath).
[lldb] Fix TestSettings.test_pass_host_env_vars on windows
Mon, Mar 30, 7:33 AM
labath closed D76835: [lldb] Fix TestSettings.test_pass_host_env_vars on windows.
Mon, Mar 30, 7:33 AM · Restricted Project
labath added inline comments to D76835: [lldb] Fix TestSettings.test_pass_host_env_vars on windows.
Mon, Mar 30, 7:33 AM · Restricted Project
labath committed rG7b00eeb53de0: [lldb] Fix another crash in covariant type handling (authored by labath).
[lldb] Fix another crash in covariant type handling
Mon, Mar 30, 7:01 AM
labath closed D76840: [lldb] Fix another crash in covariant type handling.
Mon, Mar 30, 7:01 AM · Restricted Project
labath added a comment to D76840: [lldb] Fix another crash in covariant type handling.

Thanks for the review, and a pointer to CompleteTagDeclsScope. While looking at this, I got some ideas on how to reduce the number of chained imports here (nothing magical -- just avoid importing the type if the base and derived return types are identical (no covariance). I'll try to remove the recursive imports before hacking on this further (but I don't know when exactly that will happen).

Mon, Mar 30, 7:00 AM · Restricted Project
labath added inline comments to D76814: Preserve ThreadPlanStacks for unreported threads.
Mon, Mar 30, 7:00 AM · Restricted Project
labath added a comment to D76471: Remap the target SDK directory to the host SDK directory.

I've reworked this a little based on your feedback.

First, I've renamed SDK to XcodeSDK. An Xcode SDK is a fairly specific concept and I'm not going to pretend that it makes sense to generalize it for something else, so I thought the name should reflect this. I've kept it in Utility though, since the functionality mirrors ArchSpec and one platform typically hosts many SDKs at the same time. I entertained the idea of creating a base class and each platform would implement its own SDK, which sounds neat, but with all the merging functionality needed, this doesn't really work out.

Mon, Mar 30, 5:55 AM
labath added inline comments to D76806: Remove m_last_file_sp from SourceManager.
Mon, Mar 30, 4:50 AM · Restricted Project
labath accepted D76804: Add new LLDB setting: use-source-cache.
Mon, Mar 30, 4:50 AM · Restricted Project
labath added a comment to D76805: Fix SourceManager::SourceFileCache insertion.

Does this actually depend on the other patch? It looks like an independent fix we could commit separately.

This bug seems to have existed forever. Fixing it means we will have source file cache enabled for the first time. If it causes any unforeseen issues, I'd like users to have the ability to disable the cache, which is why I made this change depend on the other change.

Mon, Mar 30, 4:50 AM · Restricted Project
labath added a comment to D75750: [lldb] integrate debuginfod.

Currently we have a solution for macOS to locate symbol files in the "lldb/source/Symbol/LocateSymbolFile.cpp" file in the Symbols::LocateExecutableSymbolFile(...) function:

static FileSpec Symbols::LocateExecutableSymbolFile(const ModuleSpec &module_spec, const FileSpecList &default_search_paths);

This will locate any files that are already on the system and return the symbol file. When you don't have a symbol file, we can call:

static bool Symbols::DownloadObjectAndSymbolFile(ModuleSpec &module_spec, bool force_lookup = true);

This might ping a build server and download the symbols.

As for source file remappings, as Jim stated, on mac, each dSYM has path remappings already inside of it that are applied on the Module (not a target wide setting) itself and no modifications need to be done to the SourceManager.

So my question is: can be use debuginfod to find the symbol file for a given build ID via Symbols::LocateExecutableSymbolFile(...), and when/if a symbol file is fetched from debuginfod, apply all path remappings to the module itself that we hand out? Then no changes would be needed in the SourceManager, we would just ask for a symbol file and get one back with all the remappings that are needed.

Mon, Mar 30, 3:12 AM · Restricted Project
labath added a comment to D73206: Pass `CompileUnit *` along `DWARFDIE` for DWZ.

Overall, I think this is workable. The main thing I don't like about the current state is the introduction of user_id_t into the index classes. It forces a bunch of conversions for a flow that really should be simple.

Mon, Mar 30, 3:12 AM · Restricted Project
labath added inline comments to D76968: [lldb-vscode] Correctly return source mapped breakpoints for setBreakpoints request.
Mon, Mar 30, 2:07 AM · Restricted Project
labath accepted D77042: [lldb] Make Fix-Its also apply to top-level expressions.

Sounds simple enough.

Mon, Mar 30, 2:07 AM · Restricted Project
labath added a comment to D77000: [LLDB] [PECOFF] Only use PECallFrameInfo on the one supported architecture.

Hello! But does the format of an exception directory for aarch64 differ completely from x86-64 one? Can we somehow adopt the existing parser to support it? If we can, I think that this check looks good (we encapsulate the difference inside PECallFrameInfo). Or may be it is worth to make a different parser for aarch64? Then I think the check would look better in ObjectFilePECOFF::CreateEHCallFrameInfo (and then we will choose a right exception directory parser depending on an architecture). What do you think on this?

Mon, Mar 30, 2:07 AM · Restricted Project
labath added a comment to D76955: [lldb/Test] Decode stdout and stderr in case it contains UTF-8.

Right, I didn't check whether out and err were strings or bytes. I'll see if I can find a better solution or alternatively wrap it in a try-except.

Mon, Mar 30, 1:35 AM
labath accepted D76945: [lldb/CMake] Make check-lldb-* work for the standalone build..

sounds reasonable

Mon, Mar 30, 1:02 AM · Restricted Project

Fri, Mar 27

labath added inline comments to D76814: Preserve ThreadPlanStacks for unreported threads.
Fri, Mar 27, 2:38 AM · Restricted Project

Thu, Mar 26

labath accepted D76672: [lldb/Reproducers] Always collect the whole dSYM in the reproducer.
Thu, Mar 26, 12:33 PM · Restricted Project
labath committed rGe22f0dabcf97: [lldb/breakpad] Fix register resolution on arm (authored by labath).
[lldb/breakpad] Fix register resolution on arm
Thu, Mar 26, 5:56 AM
labath created D76840: [lldb] Fix another crash in covariant type handling.
Thu, Mar 26, 5:55 AM · Restricted Project
labath committed rG57be22fa1797: [LLDB] Fix parsing of IPv6 host:port inside brackets (authored by emrekultursay).
[LLDB] Fix parsing of IPv6 host:port inside brackets
Thu, Mar 26, 3:45 AM
labath closed D76736: [LLDB] Fix parsing of IPv6 host:port inside brackets.
Thu, Mar 26, 3:45 AM · Restricted Project
labath created D76835: [lldb] Fix TestSettings.test_pass_host_env_vars on windows.
Thu, Mar 26, 3:45 AM · Restricted Project
labath added a comment to D76672: [lldb/Reproducers] Always collect the whole dSYM in the reproducer.

Wow. This is a lot more generic than I had mind. But at the same time, it does not seem generic enough. :( Like, for instance, using only component-based matching, one couldn't ignore /usr/lib while keeping $BUILD/lib or whatever.

Thu, Mar 26, 3:44 AM · Restricted Project
labath committed rG703a856a1005: [lldb] Fix TestVSCode_completions for clang 159a9f7 (authored by labath).
[lldb] Fix TestVSCode_completions for clang 159a9f7
Thu, Mar 26, 2:40 AM
labath added a comment to D76814: Preserve ThreadPlanStacks for unreported threads.

I still don't know much about thread plans, but I didn't see anything that would stand out. All my comments are fairly superficial.

Thu, Mar 26, 2:07 AM · Restricted Project
labath added reviewers for D76806: Remove m_last_file_sp from SourceManager: labath, jingham.

It's not clear to me what is the user-visible effect of this. It sounds like there should be one, but I don't know what it is...

Thu, Mar 26, 1:35 AM · Restricted Project
labath accepted D76805: Fix SourceManager::SourceFileCache insertion.

Looks good. I'm just picking some nits in the test. I'm assuming that @jingham's comment refers to the other patch (and it more-or-less matches what I wrote there already).

Thu, Mar 26, 1:35 AM · Restricted Project
labath added a reviewer for D76804: Add new LLDB setting: use-source-cache: jingham.

Yeah, the differences between windows&posix handling of memory mapped files is quite annoying (though I can't really say that the windows behavior is worse than randomly sending out SIGBUSes).

Thu, Mar 26, 1:03 AM · Restricted Project
labath added a comment to D76569: Convert CommandObjectCommands functions to return StringRefs.

Ah, that is cute. :) Thanks for following this up.

Thu, Mar 26, 1:03 AM · Restricted Project

Wed, Mar 25

labath committed rGc72675394a85: [lldb] add lit.local.cfg for breakpad tests (authored by labath).
[lldb] add lit.local.cfg for breakpad tests
Wed, Mar 25, 9:10 AM
labath added a comment to D76672: [lldb/Reproducers] Always collect the whole dSYM in the reproducer.

Ok, you really want to collect the full dsym, then who am I to stop you. :)

Wed, Mar 25, 2:40 AM · Restricted Project
labath accepted D76736: [LLDB] Fix parsing of IPv6 host:port inside brackets.

Looks good. You already mention that in the commit message, but it may be nice to also mention somewhere near the test case that these kinds of "URL"s can occur when and connecting to and android device over IP (in which case the port is part of the "hostname"). So one isn't left wondering why are we testing such "nonsensical" hostnames...

Wed, Mar 25, 2:08 AM · Restricted Project
labath requested changes to D75750: [lldb] integrate debuginfod.

Adding @jingham. Jim, what do you make of this patch and the feature overall?

Wed, Mar 25, 2:08 AM · Restricted Project
labath accepted D76593: [lldb-vscode] Convert launch_info and attach_info to local variables.

still lgtm, just make sure to clang-format before committing.

Wed, Mar 25, 1:03 AM · Restricted Project

Tue, Mar 24

labath added a comment to D76672: [lldb/Reproducers] Always collect the whole dSYM in the reproducer.

It's not clear to me why this is needed.

I mean, if lldb touches any of the files inside the dsym bundle, then they should be automatically recorded already, right? And if it doesn't then it does not need them...

The dSYM can contain other resources than just the Mach-O companion file, such as script for the OS plugins or opt remarks, which might not be used by the reproducers or even LLDB at all. Once you have the reproducer on your system, tools will find and use it because spotlight indexed it. Having only a partial dSYM is really undesirable as it can break LLDB and other tools in really unexpected ways.

Tue, Mar 24, 10:44 AM · Restricted Project
labath committed rGd381b6a8d3e8: [DWARF] Fix v5 debug_line parsing of prologues with many files (authored by labath).
[DWARF] Fix v5 debug_line parsing of prologues with many files
Tue, Mar 24, 7:30 AM
labath closed D76498: [DWARF] Fix v5 debug_line parsing of prologues with many files.
Tue, Mar 24, 7:30 AM · Restricted Project
labath added a comment to D75750: [lldb] integrate debuginfod.

The code mostly fine for me, but this should be reviewed by properly by more people, once you're ready to take down the WIP tag.

Tue, Mar 24, 6:57 AM · Restricted Project
labath accepted D76698: [lldb] Always log if acquiring packet sequence mutex fails.
Tue, Mar 24, 6:56 AM · Restricted Project
labath added a comment to D76672: [lldb/Reproducers] Always collect the whole dSYM in the reproducer.

It's not clear to me why this is needed.

Tue, Mar 24, 2:07 AM · Restricted Project
labath added a comment to D74636: [lldb-vscode] Add inheritEnvironment option.

I would either add the option to SBLaunchInfo so it can be specified, or execute the command. If the target is created, it is setting a target specific setting. If had to pick I would add the API to SBLaunchInfo. Whenever I see something that can't be done through the API, I like to add that API if it is warranted. In our case the value in the SBLaunchInfo should probably be stored as a lldb_private::LazyBool which can have the following values:

enum LazyBool { eLazyBoolCalculate = -1, eLazyBoolNo = 0, eLazyBoolYes = 1 };

It would eLazyBoolCalculate to in the launch info, and if it gets set to true or false, then we use that, if it is set to eLazyBoolCalculate we use the target setting.

Tue, Mar 24, 2:07 AM · Restricted Project
labath accepted D76626: [lldb/Reproducers] Collect files imported by command script import.

This seems fine with a (fairly big) caveat that this approach will not work transitively loaded modules (== if the "command script import"ed module imports another module on its own). Supporting this would be possible, but it would require hooking fairly deep into the module loading mechanism of respective language. In lua, I believe that could be achieved by overriding the builtin loadfile function (to save the file when recording, and substitute it during replay). In python, that might be achieved by overriding the __import__ function to record the module file name and by adjusting the module import mechanism (perhaps via import hooks) on replay.

Tue, Mar 24, 1:35 AM · Restricted Project
labath accepted D76569: Convert CommandObjectCommands functions to return StringRefs.

Looks good. I wouldn't be too worried about asan as a StringRef provides the same lifetime guarantees (== none) as a const char *.

Tue, Mar 24, 1:35 AM · Restricted Project

Mon, Mar 23

labath added a comment to D76593: [lldb-vscode] Convert launch_info and attach_info to local variables.

Sounds like a good idea. Could you do the same for attach_info (it looks like it should be possible)? Otherwise, one is left wondering about what's the difference...

I have that as my next patch - it seems like something that should be in a separate commit, but in the same pull request, but I don't know how to properly submit patch series for review at Phabricator - only through "related revisions", I presume?

Mon, Mar 23, 7:36 AM · Restricted Project
labath updated the diff for D76498: [DWARF] Fix v5 debug_line parsing of prologues with many files.
  • rename test, add comment
Mon, Mar 23, 3:15 AM · Restricted Project
labath added a comment to D76498: [DWARF] Fix v5 debug_line parsing of prologues with many files.

I suppose this should lead to questions about whether mis-encoded ULEBs can cause parsing sadness, and are those handled in a reasonable way?

If I'm not mistaken, the only way a ULEB could be misencoded can be detected is by it running off the end of the data (although in practice a value greater than max uint64_t will also be detected IIRC). I have a vague memory that the data extractor records an error, if using the appropriate style of parsing, but I don't think we are currently using that type in some cases, so the error is ignored.

Mon, Mar 23, 3:15 AM · Restricted Project
labath accepted D76593: [lldb-vscode] Convert launch_info and attach_info to local variables.

Sounds like a good idea. Could you do the same for attach_info (it looks like it should be possible)? Otherwise, one is left wondering about what's the difference...

Mon, Mar 23, 2:43 AM · Restricted Project
labath added a comment to D76471: Remap the target SDK directory to the host SDK directory.

Thanks for the explanation. I have some ideas on this below, though I am not sure if I know enough about the problem to be able to tell which ones are feasible.

Mon, Mar 23, 2:43 AM
labath accepted D76009: [lldb/Target] Initialize new targets environment variables from target.env-vars.
Mon, Mar 23, 1:38 AM · Restricted Project
labath added a comment to D74636: [lldb-vscode] Add inheritEnvironment option.

I added some tests cases to show why I used "settings set target.inherit-env".

There are currently two ways to launch a process. Either with the plain "program" argument,
or with the "launchCommands" argument. The latter is assumed to create a target by executing
arbitrary commands, which may go through CommandObjectProcess.

As by default target.inherit-env is true, if we first set its value to what we got from the
inheritEnvironment argument, then both kinds of launchers would behave the same way.

Mon, Mar 23, 1:06 AM · Restricted Project
labath accepted D76470: [lldb/Target] Rework the way the inferior environment is created.

looks good to me.

Mon, Mar 23, 1:06 AM · Restricted Project

Fri, Mar 20

labath created D76498: [DWARF] Fix v5 debug_line parsing of prologues with many files.
Fri, Mar 20, 8:05 AM · Restricted Project
labath added inline comments to D75562: Add an opque payload field to lldb::Type (NFC)..
Fri, Mar 20, 4:18 AM · Restricted Project
labath committed rG089cfe113da1: Improve step over performance (authored by jarin).
Improve step over performance
Fri, Mar 20, 3:46 AM
labath closed D76216: Improve step over performance.
Fri, Mar 20, 3:46 AM · Restricted Project
labath added a comment to D76168: CPlusPlusNameParser does not handles templated operator< properly.

Long-term I would like to modify clang to stop doing that for LLDB, but LLDB will still have to support older compilers for a while. So I think this fix is still needed.

So is this some alternative to D75761 (where we'd use CPlusPlusNameParser to decode DW_AT_names of templates)? If so, I think that is an interesting direction, but beware that that class is kind of meant for processing the demangler output. The contents of DW_AT_name looks a bit like a demangled name, but in reality there are some deviations from that format (which is why I did not recommend this direction initially -- but I am not against it either).

Also it looks like llvm and gnu demanglers disagree on the exact formatting of demangled operator names:

$ c++filt _ZlsI1AEvT_S1_
void operator<< <A>(A, A)
$ llvm-cxxfilt _ZlsI1AEvT_S1_
void operator<<<A>(A, A)

I think the gnu format is superior (and unambiguous) so we could change llvm to match that -- and this change probably won't require any kind of compatibility hacks.

This is not an alternative, this is a complement to that fix. So even with D75761 we still fail in expressions and setting breakpoints for symbols of that type. So both fixes are needed.

I personally would like to stop emitting template parameters for DW_AT_names but I know this will break some stuff and I have to see if it is workable or not, I think it is.

Lastly, we will still need to support older compilers regardless.

Fri, Mar 20, 3:46 AM · Restricted Project
labath added a comment to D75929: [DebugInfo] Support DWARFv5 index sections..

(btw, is there a test case for the "unknown column" code path?)

Yes, it is checked in llvm/test/DebugInfo/X86/debug-cu-index-unknown-section.s, which was added in D75609 and then extended in D75668.

Got it. Thanks.

Fri, Mar 20, 3:45 AM · Restricted Project, debug-info, Restricted Project
labath added inline comments to D75750: [lldb] integrate debuginfod.
Fri, Mar 20, 3:45 AM · Restricted Project
labath added inline comments to D74636: [lldb-vscode] Add inheritEnvironment option.
Fri, Mar 20, 3:45 AM · Restricted Project
labath accepted D76111: Create basic SBEnvironment class.

This looks good to me. I still have some doubts about the ConstStringification of the returned values (I am not a fan of constifying everything), but I don't want to block this review for that.

Fri, Mar 20, 3:13 AM · Restricted Project
labath added a comment to D76470: [lldb/Target] Rework the way the inferior environment is created.

I think this is a good change, and is in line with what we have discussed previously. I have just one question about the exact variable interactions here.

Fri, Mar 20, 2:40 AM · Restricted Project
labath requested changes to D76471: Remap the target SDK directory to the host SDK directory.

I think this needs a lot more discussion. First, there's some weird layering going on here, where the class SDK is declared in lldb/Utility, but it's implemented in PlatformDarwin. But even before we sort that out, we probably need to figure out what exactly is the scope of the new class (e.g. should it cover only Mac sdks, or more).

Fri, Mar 20, 2:08 AM
labath accepted D74398: [lldb-server] jThreadsInfo returns stack memory.

This is great. The new test looks even better than I had hoped for. Thanks for sticking with this.

Fri, Mar 20, 1:35 AM · Restricted Project
labath added a comment to D76449: [lldb/Dwarf] Change DW_OP_piece to use an llvm::BitVector (WIP).

looking forward to seeing the final form of this

Fri, Mar 20, 1:03 AM · Restricted Project
labath accepted D76314: [lldb-vscode] stop read loop after termination.
Fri, Mar 20, 12:31 AM · Restricted Project
labath added a comment to D76407: [lldb/testsuite] Remove "healthy process" test from TestProcessCrashInfo.py.

This test just seems wrong to me. We can pretend that processes that haven't crashed don't have crash_info, and manually suppress the output in lldb if the stop state isn't a crash. But it seems useful to ask "what are the crash_info bits in flight right now" even if you haven't crashed. So that doesn't seem right to me. Or you have to acknowledge that you have no way of knowing whether there is crash info data hanging around, in which case any test that depends on there being none is an invalid test. I'd delete this whole test, since it seems to me like it will only ever succeed by accident.

Fri, Mar 20, 12:30 AM · Restricted Project