Page MenuHomePhabricator
Feed Advanced Search

Today

labath committed rG7ada1c530094: Remove core loading timeout (authored by labath).
Remove core loading timeout
Tue, Jun 25, 12:17 AM
labath committed rL364276: Remove core loading timeout.
Remove core loading timeout
Tue, Jun 25, 12:15 AM
labath closed D63730: Remove core loading timeout.
Tue, Jun 25, 12:15 AM · Restricted Project
labath added a comment to D63540: Fix lookup of symbols at the same address with no size vs. size.

So I am fine with symbols having zero size being in the symbol table. I would be fine not changing anything in the sorting and leaving some symbols with zero size, we just need to fix:

Symbol *Symtab::FindSymbolAtFileAddress(addr_t file_addr);

To ignore zero sized symbols when it finds them _if_ there is another symbol that has a size for that address. Wouldn't that fix the issue here?

Tue, Jun 25, 12:12 AM · Restricted Project
labath committed rGfcad3bc41541: DWARF: Add support for type units+split dwarf combo (authored by labath).
DWARF: Add support for type units+split dwarf combo
Tue, Jun 25, 12:01 AM
labath committed rL364274: DWARF: Add support for type units+split dwarf combo.
DWARF: Add support for type units+split dwarf combo
Tue, Jun 25, 12:01 AM
labath closed D63643: DWARF: Add support for type units+split dwarf combo.
Tue, Jun 25, 12:01 AM · Restricted Project

Yesterday

labath added a comment to D63745: [CMake] Check that a certificate for lldb is present at build time..

This code should go to tools/debugserver/source/CMakeLists.txt so that it is next to the code which performs the actual code signing. Doing that will make it easier to keep it in sync with changes to code signing, as well as make it obvious that it is not in sync with them right now (there's a pretty complex interaction of various cmake options (LLDB_CODESIGN_IDENTITY, LLVM_CODESIGNING_IDENTITY, LLDB_USE_SYSTEM_DEBUGSERVER, etc.) which affects code signing, and this code is ignoring all of those)...

Mon, Jun 24, 11:45 PM · Restricted Project
labath created D63730: Remove core loading timeout.
Mon, Jun 24, 10:56 AM · Restricted Project
labath added inline comments to D63713: WIP: DataExtractor error handling.
Mon, Jun 24, 9:59 AM · Restricted Project
labath added a comment to D63713: WIP: DataExtractor error handling.

Besides prototyping the "DataStream" class, this also converts debug_loc and accel table (the two pieces of code I'm familiar with) parsers to use it in order to demonstrate how would this look in action.

Mon, Jun 24, 6:49 AM · Restricted Project
labath created D63713: WIP: DataExtractor error handling.
Mon, Jun 24, 6:31 AM · Restricted Project
labath added a comment to D63591: DWARFDebugLoc: Make parsing and error reporting more robust.

Given figuring out error handling for DataExtractor is perhaps a wider issue - if you want to go ahead with this change (continue with the review & defer error handling improvements for later, leave a FIXME, etc) that seems fine.

Mon, Jun 24, 6:13 AM · Restricted Project
labath updated the diff for D63591: DWARFDebugLoc: Make parsing and error reporting more robust.

Leave a TODO in the code.

Mon, Jun 24, 6:08 AM · Restricted Project
labath committed rGbb6d0b8e7b0d: [Support] Fix error handling in DataExtractor::get[US]LEB128 (authored by labath).
[Support] Fix error handling in DataExtractor::get[US]LEB128
Mon, Jun 24, 2:12 AM
labath committed rL364169: [Support] Fix error handling in DataExtractor::get[US]LEB128.
[Support] Fix error handling in DataExtractor::get[US]LEB128
Mon, Jun 24, 2:12 AM
labath closed D63645: [Support] Fix error handling in DataExtractor::get[US]LEB128.
Mon, Jun 24, 2:12 AM · Restricted Project
labath updated the diff for D63643: DWARF: Add support for type units+split dwarf combo.

Add some comments in SymbolFileDWARFDwo::ComputeCompileUnit

Mon, Jun 24, 2:06 AM · Restricted Project
labath added inline comments to D63643: DWARF: Add support for type units+split dwarf combo.
Mon, Jun 24, 2:04 AM · Restricted Project
labath added inline comments to D63165: Initial support for native debugging of x86/x64 Windows processes.
Mon, Jun 24, 1:51 AM · Restricted Project
labath added a comment to D63622: [Target] Hoist LanguageRuntime::GetDeclVendor.

The runtime DeclVendor gives runtimes a way to produce type information from runtime metadata. For instance, the ObjC runtime tables actually have fairly good type information for all ObjC classes - both instance variables, properties and methods. It is a little lossy, but for instance it knows the return types of methods so with this augmentation users can call ObjC methods without requiring casting... This is just the code to query the runtime's DeclVendors to see if they know anything about a given typename.

ObjC is a bit obnoxious, because you can define instance variables and methods in the implementation of a class as well as its interface. So even though you might have a debug info definition for the type - gotten from including the interface header file - that may not be as good as what you can get from the runtime. But the runtime type info is, as I said, lossy so if you DO have debug info it will be better. That means for ObjC you have to do some kind of merge operation to get the best information for a type. That complexity doesn't affect this patch, but I couldn't resist the opportunity to moan about it a bit since it's given US so much grief over the years!

Mon, Jun 24, 1:06 AM · Restricted Project

Fri, Jun 21

labath added inline comments to D63165: Initial support for native debugging of x86/x64 Windows processes.
Fri, Jun 21, 8:46 AM · Restricted Project
labath added a comment to D63591: DWARFDebugLoc: Make parsing and error reporting more robust.

Ah, hadn't considered statefulness. But if you layer another class on top of DataExtractor to handle the error flag, it would have to be replicating all the offset-is-valid checks, because of course DataExtractor itself doesn't return errors.

Fri, Jun 21, 7:17 AM · Restricted Project
labath added a comment to D63610: [lldb] [Process] Introduce common helpers to split/recombine YMM data.

It's not much, but it definitely does help.

// NB: I have no clue why FreeBSD code claims to belong in 'POSIX', and Linux does not.

I think that somehow fell out of the fact that FreeBSD uses an in-process debugging plugin, while linux uses lldb-server.

Ok, then I probably don't have to worry about porting NetBSD to reuse that stuff ;-).

Fri, Jun 21, 6:22 AM · Restricted Project
labath added a comment to D63591: DWARFDebugLoc: Make parsing and error reporting more robust.

The idea for error handling for DataExtractor sounds reasonable, looks like adding an error flag wouldn't even increase the size.

Fri, Jun 21, 6:18 AM · Restricted Project
labath created D63645: [Support] Fix error handling in DataExtractor::get[US]LEB128.
Fri, Jun 21, 5:08 AM · Restricted Project
labath updated the diff for D63591: DWARFDebugLoc: Make parsing and error reporting more robust.
  • remove fancy references
  • remove llvm_unreachable
Fri, Jun 21, 4:56 AM · Restricted Project
labath added inline comments to D63591: DWARFDebugLoc: Make parsing and error reporting more robust.
Fri, Jun 21, 4:56 AM · Restricted Project
labath created D63643: DWARF: Add support for type units+split dwarf combo.
Fri, Jun 21, 4:24 AM · Restricted Project
labath committed rG3b9269882e26: DWARF: Add "dwo_num" field to the DIERef class (authored by labath).
DWARF: Add "dwo_num" field to the DIERef class
Fri, Jun 21, 12:56 AM
labath committed rL364009: DWARF: Add "dwo_num" field to the DIERef class.
DWARF: Add "dwo_num" field to the DIERef class
Fri, Jun 21, 12:53 AM
labath closed D63428: DWARF: Add "dwo_num" field to the DIERef class.
Fri, Jun 21, 12:53 AM · Restricted Project
labath accepted D63610: [lldb] [Process] Introduce common helpers to split/recombine YMM data.

It's not much, but it definitely does help.

Fri, Jun 21, 12:48 AM · Restricted Project
labath added a comment to D62504: Avoid calling LoadModules twice when modules change.

Sorry, I missed this patch. Overall, this seems fine to me. I have only two comments about it:

  • I'm not sure the CanLoadModules functions is really needed. It seems like we could just call LoadModules directly and check for error result. The XMLEnabled() && ... check could be done at the start of the LoadModules function. It looks like it already is there ProcessGDBRemote::GetLoadedModuleList, but it looks like that function accidentally returns a success error code instead of failure.
  • Looking at the implementation of ProcessGDBRemote::LoadModules, I get the feeling it will return 0 if you call it when a module gets unloaded (although it will correctly unload the module, and correctly *not* load any new module). This is not a bug in this patch, so I'd be fine with checking it in without fixing that, but this sounds like something you would want to fix, as it will cause you to stop using the gdb-remote packet as soon as the first module is unloaded.

It looks like a single solution fixing both of these issues would be to change the LoadModules function to return Expected<size_t>. That way it could report the error states explicitly (such as when the svr packet is not supported or it just returns bogus data), and zero when it correctly did not load anything. (Or, given that the number of loaded modules is not particularly useful, and it does even not capture the effect of the function very precisely, the result could just be an Error).

Fri, Jun 21, 12:35 AM · Restricted Project

Thu, Jun 20

labath edited reviewers for D63622: [Target] Hoist LanguageRuntime::GetDeclVendor, added: jingham; removed: labath.

Seems like a reasonable thing to do, but I don't really know what this code does...

Thu, Jun 20, 11:58 PM · Restricted Project
labath resigned from D63240: [Core] Generalize ValueObject::IsRuntimeSupportValue.

I'm not familiar with the code enough to make the calls here.

Thu, Jun 20, 11:55 PM
labath updated the diff for D63591: DWARFDebugLoc: Make parsing and error reporting more robust.
  • add createOverflowError helper
  • use unique file names in tests
Thu, Jun 20, 6:25 AM · Restricted Project
labath added inline comments to D63591: DWARFDebugLoc: Make parsing and error reporting more robust.
Thu, Jun 20, 6:25 AM · Restricted Project
labath accepted D63594: [lldb] [Process/NetBSD] Remove unnecessary register buffer abstraction.

Yes, that's exactly what I had in mind. Let's ship it.

Thu, Jun 20, 5:15 AM · Restricted Project
labath added a comment to D63594: [lldb] [Process/NetBSD] Remove unnecessary register buffer abstraction.

BTW, is ReadGPR even called from some other place than NativeRegisterContextNetBSD_x86_64::ReadRegisterSet ? If not, then we could remove all of these functions (except the ReadRegisterSet I suggest above), and inline everything into NativeRegisterContextNetBSD_x86_64::ReadRegisterSet (one of these should be renamed, obviously), removing about 5 layers of indirection...

I think the idea is that they will be reused when we introduce additional architectures.

Thu, Jun 20, 4:47 AM · Restricted Project
labath added a comment to D63545: [lldb] [Process/NetBSD] Support reading YMM registers via PT_*XSTATE [DO NOT MERGE].

Maybe have GetYMM(unsigned num, YMM& reg)/SetYMM(unsigned num, const YMM &reg) methods on the XSAVE struct ?

We aren't using XSAVE struct. We are using NetBSD-specific struct xstate that has guaranteed fixed offsets.

Thu, Jun 20, 4:42 AM
labath added a comment to D63594: [lldb] [Process/NetBSD] Remove unnecessary register buffer abstraction.

BTW, is ReadGPR even called from some other place than NativeRegisterContextNetBSD_x86_64::ReadRegisterSet ? If not, then we could remove all of these functions (except the ReadRegisterSet I suggest above), and inline everything into NativeRegisterContextNetBSD_x86_64::ReadRegisterSet (one of these should be renamed, obviously), removing about 5 layers of indirection...

Thu, Jun 20, 4:37 AM · Restricted Project
labath added a comment to D63594: [lldb] [Process/NetBSD] Remove unnecessary register buffer abstraction.

How about we go even a bit further? The non-Do functions are now so trivial that the Do functions could be inlined into them, producing something like return NativeProcessNetBSD::PtraceWrapper(PT_GETFPREGS, GetProcessPid(), GetFPRBuffer(),m_thread.GetID());. If you wanted to be really fancy, you could define a function like ReadRegisterSet(T regset, void *buffer), and call make that be ReadRegisterSet(PT_GETFPREGS, GetFPRBuffer());

Thu, Jun 20, 4:28 AM · Restricted Project
labath added a comment to D63545: [lldb] [Process/NetBSD] Support reading YMM registers via PT_*XSTATE [DO NOT MERGE].

We have the same XSTATE<->YMM conversion functions in NativeProcessLinux. It would be nice to extract them to some common place (Plugins/Process/Utility, I guess :P).

Hmm, I guess that's doable if we pass the relevant struct fields as pointers.

Maybe have GetYMM(unsigned num, YMM& reg)/SetYMM(unsigned num, const YMM &reg) methods on the XSAVE struct ?

Thu, Jun 20, 4:13 AM
labath added a comment to D63545: [lldb] [Process/NetBSD] Support reading YMM registers via PT_*XSTATE [DO NOT MERGE].

We have the same XSTATE<->YMM conversion functions in NativeProcessLinux. It would be nice to extract them to some common place (Plugins/Process/Utility, I guess :P). The rest seems pretty straight-forward, though you're repeating the patterns that I find really reduntant/annoying. Eg. I don't see the reason to check the null-ness of the XState buffer. It sounds like it should be a hard error for someone to call ReadXState without bothering to arrange for the storage buffer to exist.

Thu, Jun 20, 3:14 AM
labath created D63591: DWARFDebugLoc: Make parsing and error reporting more robust.
Thu, Jun 20, 3:01 AM · Restricted Project
labath committed rG5418d335e1d8: Fix -Wmismatched-tags introduced in r363910 (authored by labath).
Fix -Wmismatched-tags introduced in r363910
Thu, Jun 20, 2:44 AM
labath committed rL363915: Fix -Wmismatched-tags introduced in r363910.
Fix -Wmismatched-tags introduced in r363910
Thu, Jun 20, 2:43 AM
labath updated the diff for D63428: DWARF: Add "dwo_num" field to the DIERef class.
  • use uint32_t for bitfields
  • pass DIERefs by value
  • implement GetUID so that it is structurally similar to the decoding code in DecodeUID
Thu, Jun 20, 2:35 AM · Restricted Project
labath added inline comments to D63428: DWARF: Add "dwo_num" field to the DIERef class.
Thu, Jun 20, 2:35 AM · Restricted Project
labath committed rG0de98ebd00d1: DWARF: Provide accessors to DIERef fields (authored by labath).
DWARF: Provide accessors to DIERef fields
Thu, Jun 20, 1:23 AM
labath committed rL363910: DWARF: Provide accessors to DIERef fields.
DWARF: Provide accessors to DIERef fields
Thu, Jun 20, 1:23 AM
labath closed D63400: DWARF: Provide accessors to DIERef fields.
Thu, Jun 20, 1:23 AM · Restricted Project

Wed, Jun 19

labath added a comment to D63544: Use object library if cmake supports it.

why not just change lldb-mi-utils into a conventional (STATIC) library, at which point it can just be linked in using regular target_link_libraries, which has worked since forever?

Wed, Jun 19, 5:28 AM · Restricted Project, Restricted Project
labath added a comment to D63540: Fix lookup of symbols at the same address with no size vs. size.

The fix seems reasonable to me. There's just one thing I don't get: Why was it necessary to change the iteration order here?
IIUC, the real business happens on line 904, where you add the if (entry[i].base == entry[i+1].base) break; check. I could be missing something, but it seems to me like that thing would work no matter what the iteration order is...

Wed, Jun 19, 4:37 AM · Restricted Project
labath updated the diff for D63428: DWARF: Add "dwo_num" field to the DIERef class.

Remove the cu_offset field from DIERef, bringing the total size back down to "8", as dicussed here, and on D63491.

Wed, Jun 19, 2:01 AM · Restricted Project
labath added a comment to D62502: Implement xfer:libraries-svr4:read packet.

As I kind of expected, one of these tests was flaky because the names for the vdso pseudo-module were not adding up. When reading from /proc/%pid/maps, we got "[vdso]" (as that's how the kernel likes to call this page), but while reading the linker rendezvous structure, we got "linux-vdso.so.1" (I guess that's the SONAME of the module or something).

Wed, Jun 19, 1:42 AM · Restricted Project, Restricted Project
labath committed rG80b6b705f871: Stabilize TestGdbRemoteLibrariesSvr4Support (authored by labath).
Stabilize TestGdbRemoteLibrariesSvr4Support
Wed, Jun 19, 1:41 AM
labath committed rL363772: Stabilize TestGdbRemoteLibrariesSvr4Support.
Stabilize TestGdbRemoteLibrariesSvr4Support
Wed, Jun 19, 1:38 AM
labath committed rG73a28f064328: Fix a dangling StringRef in FileCollector (authored by labath).
Fix a dangling StringRef in FileCollector
Wed, Jun 19, 1:07 AM
labath committed rL363770: Fix a dangling StringRef in FileCollector.
Fix a dangling StringRef in FileCollector
Wed, Jun 19, 1:07 AM
labath committed rG67b45acefefb: DWARF: Make DIERefs always valid (authored by labath).
DWARF: Make DIERefs always valid
Wed, Jun 19, 12:31 AM
labath committed rL363767: DWARF: Make DIERefs always valid.
DWARF: Make DIERefs always valid
Wed, Jun 19, 12:31 AM
labath closed D63399: DWARF: Make DIERefs always valid.
Wed, Jun 19, 12:31 AM · Restricted Project
labath added a comment to D63363: [Signals] Create a plugin directory just for signals.

Although this is technically correct and pretty consistent with our other "plugins", I can't help but feel that it's incredibly wasteful. Each of the XXXSignals.cpp files is less than a 100 lines long (with the licence header and all bolierplate) and it's unlikely to ever grow beyond that. And essentially, all these files do is define a single enum. The reason they are this long is because the UnixSignals class is already over-engineered (e.g. I don't see why LinuxSignals needs to be a separate class, or why it needs to repeat the descriptions/default stop values for each of the signals). Making this a plugin would just add another chunk of boilerplate on top of that.

I don't know about others, but I'd rather us move in a direction which reduces the amount of boilerplate instead of adding more of it. In my ideal world, each of these signal definitions would just be a bunch of (number, name) pairs. This doesn't have/need to be a class or a plugin; a single constexpr variable would suffice for that. Then we'd just cross-reference this mapping with another one which gives the default stop values and descriptions for each of the signals, and that's it.

I know I am repeating myself, but each time I say this, it's because I find another reason for it: I think we should start a new library which I would roughly define as "utilities for describing and manipulating various low-level aspects of processes, but which is agnostic of any actual process class". The idea would be that we can shove here all classes which are shared between lldb-server liblldb. UnixSignals would be one candidate for it. AuxVector, MemoryRegionInfo are others. Plugins/Process/Utility (where most of the signal classes live) would be a pretty good place for it already, were it not for the "Plugins" part (it would be weird for non-plugin code to depend on something called a "plugin"). However, maybe we could just create a new top-level library called "ProcessUtil" (or whatever name we come up with) and move the relevant stuff there.

Anyway, TL;DR: I think this should be handled differently. However, if others are fine with this approach, then feel free to ignore me.

How would you bind a particular variant of UnixSignals to the process plugin that it goes along with in this scenario?

Wed, Jun 19, 12:00 AM

Tue, Jun 18

labath accepted D63530: [swig] Define attribute(ref) instead of accessing swig internals..

I'm not terribly familiar with this, but it definitely looks like a more idiomatic way to do these things.

Tue, Jun 18, 11:47 PM · Restricted Project
labath added a comment to D62213: [ABI] Implement Windows ABI for x86_64.

Maybe we should make the SysV abi plugin match unknown oss too...

I'm not sure this is the right thing to do, but this should fix the problem.

It would at least preserve status quo. Not much, but it is something...

Tue, Jun 18, 11:37 PM · Restricted Project, Restricted Project
labath added a comment to D62213: [ABI] Implement Windows ABI for x86_64.

the OS check in SysV x64 ABI broke the test SymbolFile/DWARF/debug_loc.s

Tue, Jun 18, 10:58 AM · Restricted Project, Restricted Project
labath abandoned D63491: DWARF: Use a more compact internal representation in the manual dwarf index.

Ok, sounds good. In that case, I think I can squeeze that change into the previous patch in this series.

Tue, Jun 18, 7:22 AM
labath added a comment to D63491: DWARF: Use a more compact internal representation in the manual dwarf index.

I made this depend on the DIERef patch instead of the other way around because the cleaner separation between dwo identifiers and compile unit offsets implemented in that patch makes it easier to implement this. It would still be possible to implement it the other way around, but the logic would be more complex, and it would have to be redone anyway once the DIERef patch lands.

Tue, Jun 18, 6:33 AM
labath added a parent revision for D63491: DWARF: Use a more compact internal representation in the manual dwarf index: D63428: DWARF: Add "dwo_num" field to the DIERef class.
Tue, Jun 18, 6:28 AM
labath added a child revision for D63428: DWARF: Add "dwo_num" field to the DIERef class: D63491: DWARF: Use a more compact internal representation in the manual dwarf index.
Tue, Jun 18, 6:28 AM · Restricted Project
labath created D63491: DWARF: Use a more compact internal representation in the manual dwarf index.
Tue, Jun 18, 6:28 AM
labath updated the diff for D63428: DWARF: Add "dwo_num" field to the DIERef class.
  • use the existing function for DWARFDIE->DIERef conversion
  • fix a bug where we were ignoring the dwo_num and section fields when searching for all entries in a given unit. Technically, this was incorrect even when we introduced the "section" field, but there it did not matter because this function is only used for searching for global variables, and those don't appear in a type unit. Add a test.
Tue, Jun 18, 6:16 AM · Restricted Project
labath added a comment to D63428: DWARF: Add "dwo_num" field to the DIERef class.

I've been thinking about the DIERef class a lot while doing this, and the more I thought about it, the more I became convinced that forcing everything to go through DIERefs is not a good idea. It is kind of useful to have it as a sort of exchange currency between various components, but that means it forces an particular access pattern for the debug info, one which may not be always optimal. For example, there's no reason why the manual index would need to use offsets of anything. Offsets require binary search, but the manual index has already gone through the debug info once, so it can easily remember the indexes of everything. Indexes don't need binary search, and they can be stored more compactly. Even for the debug_names index, which does use offsets, the DIERef representation is not the ideal form. That's because it uses unit-relative die indexes while DIERef stores the absolute index. This means it still has to look up the DWO unit in order to correctly construct an absolute die offset.

Tue, Jun 18, 6:16 AM · Restricted Project
labath added a comment to D63268: Make UniqueCStringMap work with non-default-constructible types and other improvements/cleanups.

Thanks for the heads up. This should be fixed with r363653.

Tue, Jun 18, 12:41 AM · Restricted Project
labath accepted D63467: [Reproducers] Make reproducer relocatable.
Tue, Jun 18, 12:16 AM · Restricted Project, Restricted Project
labath accepted D63166: Move common functionality from processwindows into processdebugger.
Tue, Jun 18, 12:06 AM · Restricted Project
labath committed rGafb17daedf95: Fix windows build for r363357 (authored by labath).
Fix windows build for r363357
Tue, Jun 18, 12:01 AM
labath committed rL363653: Fix windows build for r363357.
Fix windows build for r363357
Tue, Jun 18, 12:01 AM

Mon, Jun 17

labath accepted D62503: Add ReadCStringFromMemory for faster string reads.
Mon, Jun 17, 11:13 PM · Restricted Project, Restricted Project
labath accepted D63441: [zorg] Add lldb-arm-ubuntu builder.

lgtm

Mon, Jun 17, 12:24 PM · Restricted Project
labath added a comment to D63363: [Signals] Create a plugin directory just for signals.
In D63363#1546504, @jfb wrote:
In D63363#1546464, @jfb wrote:

Can you describe what the goal of your plugin architecture is? Maybe you need an RFC by email before moving stuff around.

I want to understand what you're going for because as they are today the signals mostly work, and aren't really tested (because injecting these conditions isn't trivial). Anything you change is likely to break some subtle invariant which will only repro when your change is deployed at scale.

My goal is to remove non-plugin libraries dependencies on plugins. Today, Target depends on the ProcessUtility plugin because of UnixSignals. If Signals were their own plugin that could be accessed through the PluginManager interface, that dependency would go away. As Pavel said, this feels somewhat over engineered and contrived, but it is the simplest path forward. I am willing to drop this patch and go for a different solution if there is a nicer solution agreed upon by the community, so an RFC sounds like a nice idea. :)

Removing the dependency seems fine, but we have to be careful with how signals work: they're inherently global state, and you want to register / de-register them exactly where they're registered / de-registered right now to keep them working exactly the same. If you change this, we need to really think through why that's a good idea (it might be!).

Mon, Jun 17, 12:20 PM
labath added a comment to D63399: DWARF: Make DIERefs always valid.

I am concerned that our mapping from DIERef to lldb::user_id_t won't work for all cases now that we are/have expanded the DIERef class (including as we add the DWO field). I voiced this concern in https://reviews.llvm.org/D63428. Let me know what you think.

Mon, Jun 17, 12:17 PM · Restricted Project
labath accepted D63339: Extend D55859 symbols.enable-external-lookup=false for more testcases.

It looks like lldb-mi has the --source option. Could that be used to set this setting automatically via lit, as it is done with %lldb ?

The problem is it generates additional ^done line

echo 'settings set symbols.enable-external-lookup false' >/tmp/1j;lldb-mi --source /tmp/1j
(gdb)
settings set symbols.enable-external-lookup false
^done
(gdb)
which the scripts do not expect. They already expect such "unexpected" response from a commandline parameter the scripts pass themselves (`%t`):
# RUN: %lldbmi %t < %s | FileCheck %s
# Check that we have a valid target created via '%lldbmi %t'.
# CHECK: ^done

This would mean adding additional one # CHECK: ^done for the settings set symbols.enable-external-lookup false command which is not present in the script which I hope you agree is worse than adding both that command+its response as I did.
Or did you mean it some different way? Thanks for the review.

Mon, Jun 17, 7:19 AM · Restricted Project, Restricted Project
labath added a comment to D63339: Extend D55859 symbols.enable-external-lookup=false for more testcases.

It looks like lldb-mi has the --source option. Could that be used to set this setting automatically via lit, as it is done with %lldb ?

Mon, Jun 17, 6:57 AM · Restricted Project, Restricted Project
labath added inline comments to D63166: Move common functionality from processwindows into processdebugger.
Mon, Jun 17, 6:51 AM · Restricted Project
labath added inline comments to D63165: Initial support for native debugging of x86/x64 Windows processes.
Mon, Jun 17, 6:35 AM · Restricted Project
labath added a parent revision for D63428: DWARF: Add "dwo_num" field to the DIERef class: D63400: DWARF: Provide accessors to DIERef fields.
Mon, Jun 17, 6:25 AM · Restricted Project
labath added a child revision for D63400: DWARF: Provide accessors to DIERef fields: D63428: DWARF: Add "dwo_num" field to the DIERef class.
Mon, Jun 17, 6:25 AM · Restricted Project
labath created D63428: DWARF: Add "dwo_num" field to the DIERef class.
Mon, Jun 17, 6:22 AM · Restricted Project
labath updated the diff for D63400: DWARF: Provide accessors to DIERef fields.
  • s/DW_INVALID_OFFSET/llvm::None/ in HashedNameToDIE.h
Mon, Jun 17, 2:23 AM · Restricted Project
labath added a comment to D63400: DWARF: Provide accessors to DIERef fields.

(also, cu_offset is renamed to unit_offset, as we now support type units too)

Mon, Jun 17, 2:11 AM · Restricted Project
labath added a parent revision for D63400: DWARF: Provide accessors to DIERef fields: D63399: DWARF: Make DIERefs always valid.
Mon, Jun 17, 2:11 AM · Restricted Project
labath added a child revision for D63399: DWARF: Make DIERefs always valid: D63400: DWARF: Provide accessors to DIERef fields.
Mon, Jun 17, 2:11 AM · Restricted Project
labath created D63400: DWARF: Provide accessors to DIERef fields.
Mon, Jun 17, 2:11 AM · Restricted Project
labath added inline comments to D63399: DWARF: Make DIERefs always valid.
Mon, Jun 17, 1:44 AM · Restricted Project
labath created D63399: DWARF: Make DIERefs always valid.
Mon, Jun 17, 1:44 AM · Restricted Project
labath accepted D63380: [lldb] [test] Skip watchpoint tests on NetBSD if userdbregs is disabled.
Mon, Jun 17, 1:16 AM · Restricted Project
labath committed rGa71ce4f1e8e1: DWARF: Avoid storing DIERefs in long-lived containers (authored by labath).
DWARF: Avoid storing DIERefs in long-lived containers
Mon, Jun 17, 12:31 AM