labath (Pavel Labath)
User

Projects

User does not belong to any projects.

User Details

User Since
Jun 4 2013, 6:02 AM (277 w, 18 h)

Recent Activity

Yesterday

labath accepted D52516: [lldbinline] Set directory attribute on test-specific classes.

Ooh, nice catch. This must have been fun to debug.

Tue, Sep 25, 1:13 PM
labath committed rL343016: XFAIL some tests in TestTargetCreateDeps on linux.
XFAIL some tests in TestTargetCreateDeps on linux
Tue, Sep 25, 12:53 PM
labath committed rLLDB343016: XFAIL some tests in TestTargetCreateDeps on linux.
XFAIL some tests in TestTargetCreateDeps on linux
Tue, Sep 25, 12:53 PM
labath accepted D52498: [lldb-mi] Fix bugs in target-select-so-path.test.

LGTM. (BTW, python 3.1's EOL was 6 years ago)

Tue, Sep 25, 12:40 PM
labath added a comment to D52461: [PDB] Introduce `PDBNameParser`.

I think you should look at CPlusPlusLanguage::MethodName. It already contains a parser (in fact, two of them) of c++ names, and I think it should be easy to extend it to do what you want.

Tue, Sep 25, 7:01 AM · Restricted Project
labath added a comment to D52139: [lldb-mi] Fix hanging of target-select-so-path.test.

Anyway, the actual issue is related Python 3: Arch Linux (and probably
some other distributions that "already" upgraded to Python 3 as
default) will launch Python 3 when the test script calls python ....
And for some reason in Python 3.7, we will not inherit our FD from our
pipe to the subprocess, which causes this strange behavior when write
to the unrelated FD number in ConnectToRemote. When I explicitly call
Python 2.7 from the test, everything runs as expected.

The python docs don't see to mention this change (and it seems like a
bug to me), so I'm open for ideas how to fix this properly. In any
case this problem doesn't block this review.

Tue, Sep 25, 6:55 AM
labath added a comment to D48393: Make DWARFParsing more thread-safe.

The only sane algorithm I can come up right now is to make the list of parsed dies local to each thread/parsing entity (e.g. via a "visited" list), and only update the global map once the parsing has completed (successfully or not). This can potentially duplicate some effort where one thread parses a type only to find out that it has already been parsed, but hopefully that is not going to be the common case. The alternative is some complicated resource cycle detection scheme.

I gave this a shot in D52406 but I'm afraid it's too simple to be correct. Pavel, could you give it a look and let me know whether that was what you had in mind?

Tue, Sep 25, 5:32 AM

Mon, Sep 24

labath committed rL342875: Add NativeProcessProtocol unit tests.
Add NativeProcessProtocol unit tests
Mon, Sep 24, 7:24 AM
labath committed rLLDB342875: Add NativeProcessProtocol unit tests.
Add NativeProcessProtocol unit tests
Mon, Sep 24, 7:24 AM
This revision was not accepted when it landed; it landed in state Needs Review.
Mon, Sep 24, 7:24 AM
labath added a comment to D52403: [LLDB] - Support the single file split DWARF..

I believe you should be able to use lldb-test to write this kind of a test. I am thinking of a sequence like:

yaml2obj %p/Inputs/test.yaml > %t/test.yaml
yaml2obj %p/Inputs/test.o.yaml > %t/test.o.yaml
lldb-test breakpoint %t/test.yaml %s | FileCheck %s
b main
CHECK-LABEL: b main
CHECK: Address: {{.*}}main + 13 at test.cpp:2:3
Mon, Sep 24, 7:20 AM

Sun, Sep 16

labath created D52152: Add NativeProcessProtocol unit tests.
Sun, Sep 16, 12:02 PM

Fri, Sep 14

labath added a comment to D51566: Add a relocation to ObjectFileELF::ApplyRelocations and a test.

I am not sure which thread it was, but I think I mentioned somewhere that lldb-test would be better suited to write this kind of a test. bin/lldb-test object-file -contents should print the contents of the sections, which should reflect the relocations that have been applied to them. Then you could write the test as:
yaml2obj | lldb-test object-file -contents | FileCheck

Fri, Sep 14, 8:44 AM

Thu, Sep 13

labath committed rLLDB342167: NativeProcessProtocol: Sink ReadMemoryWithoutTrap into base class.
NativeProcessProtocol: Sink ReadMemoryWithoutTrap into base class
Thu, Sep 13, 1:19 PM
labath committed rL342167: NativeProcessProtocol: Sink ReadMemoryWithoutTrap into base class.
NativeProcessProtocol: Sink ReadMemoryWithoutTrap into base class
Thu, Sep 13, 1:18 PM

Wed, Sep 12

labath added a comment to D51966: Do not create new terminals when launching process on Windows with --no-stdio.

This makes sense to me, but the windows folks should say what is best for their platform.

Wed, Sep 12, 9:48 AM
labath committed rL342051: Fix two issues in PDBASTParser.
Fix two issues in PDBASTParser
Wed, Sep 12, 5:27 AM
labath committed rLLDB342051: Fix two issues in PDBASTParser.
Fix two issues in PDBASTParser
Wed, Sep 12, 5:27 AM
labath committed rLLDB342050: Move SafeMachO from Utility to Host.
Move SafeMachO from Utility to Host
Wed, Sep 12, 5:27 AM
labath committed rL342050: Move SafeMachO from Utility to Host.
Move SafeMachO from Utility to Host
Wed, Sep 12, 5:27 AM
labath closed D50383: Move SafeMachO from Utility to Host.
Wed, Sep 12, 5:27 AM
labath updated the diff for D50383: Move SafeMachO from Utility to Host.

Add the file to module map.

Wed, Sep 12, 4:13 AM
labath committed rLLDB342029: Reduce alignment on struct XSAVE, fixing a gcc warning.
Reduce alignment on struct XSAVE, fixing a gcc warning
Wed, Sep 12, 1:53 AM
labath committed rL342029: Reduce alignment on struct XSAVE, fixing a gcc warning.
Reduce alignment on struct XSAVE, fixing a gcc warning
Wed, Sep 12, 1:53 AM
labath added a comment to D51966: Do not create new terminals when launching process on Windows with --no-stdio.

I think the issue here is that on windows we don't have the ability(*) to pipe stdio through lldb, so if you create a process without a console, you will not be able to use see it's output or pass it some input (probably fine for gui apps, but bad for console ones). This means your approach will also make things inconsistent with other platforms, only in a different way. (I don't really have an opinion which one is better/worse.)

Wed, Sep 12, 1:31 AM
labath accepted D51959: Add compatability version to liblldb in framework builds.

lgtm modulo typos

Wed, Sep 12, 1:23 AM

Sun, Sep 9

labath committed rLLDB341759: Speculative fix for NetBSD bot for r341758.
Speculative fix for NetBSD bot for r341758
Sun, Sep 9, 1:44 AM
labath committed rL341759: Speculative fix for NetBSD bot for r341758.
Speculative fix for NetBSD bot for r341758
Sun, Sep 9, 1:44 AM

Sat, Sep 8

labath committed rLLDB341758: Re-commit "Modernize NativeProcessProtocol::GetSoftwareBreakpointTrapOpcode".
Re-commit "Modernize NativeProcessProtocol::GetSoftwareBreakpointTrapOpcode"
Sat, Sep 8, 11:05 PM
labath committed rL341758: Re-commit "Modernize NativeProcessProtocol::GetSoftwareBreakpointTrapOpcode".
Re-commit "Modernize NativeProcessProtocol::GetSoftwareBreakpointTrapOpcode"
Sat, Sep 8, 11:05 PM
labath committed rLLDB341747: Revert "Modernize NativeProcessProtocol::GetSoftwareBreakpointTrapOpcode".
Revert "Modernize NativeProcessProtocol::GetSoftwareBreakpointTrapOpcode"
Sat, Sep 8, 3:34 AM
labath committed rL341747: Revert "Modernize NativeProcessProtocol::GetSoftwareBreakpointTrapOpcode".
Revert "Modernize NativeProcessProtocol::GetSoftwareBreakpointTrapOpcode"
Sat, Sep 8, 3:34 AM

Thu, Sep 6

labath committed rL341564: Re-commit "Enable DWARF accelerator tables by default when tuning for lldb….
Re-commit "Enable DWARF accelerator tables by default when tuning for lldb…
Thu, Sep 6, 10:06 AM
labath committed rC341564: Re-commit "Enable DWARF accelerator tables by default when tuning for lldb….
Re-commit "Enable DWARF accelerator tables by default when tuning for lldb…
Thu, Sep 6, 10:05 AM

Wed, Sep 5

labath committed rC341492: Revert "Enable DWARF accelerator tables by default when tuning for lldb (-glldb….
Revert "Enable DWARF accelerator tables by default when tuning for lldb (-glldb…
Wed, Sep 5, 1:21 PM
labath committed rL341492: Revert "Enable DWARF accelerator tables by default when tuning for lldb (-glldb….
Revert "Enable DWARF accelerator tables by default when tuning for lldb (-glldb…
Wed, Sep 5, 1:21 PM
labath committed rLLDB341487: Modernize NativeProcessProtocol::GetSoftwareBreakpointTrapOpcode.
Modernize NativeProcessProtocol::GetSoftwareBreakpointTrapOpcode
Wed, Sep 5, 11:10 AM
labath committed rL341487: Modernize NativeProcessProtocol::GetSoftwareBreakpointTrapOpcode.
Modernize NativeProcessProtocol::GetSoftwareBreakpointTrapOpcode
Wed, Sep 5, 11:10 AM
labath committed rC341472: Enable DWARF accelerator tables by default when tuning for lldb (-glldb =>….
Enable DWARF accelerator tables by default when tuning for lldb (-glldb =>…
Wed, Sep 5, 7:40 AM
labath committed rL341472: Enable DWARF accelerator tables by default when tuning for lldb (-glldb =>….
Enable DWARF accelerator tables by default when tuning for lldb (-glldb =>…
Wed, Sep 5, 7:40 AM
labath closed D51576: Enable DWARF accelerator tables by default when tuning for lldb (-glldb => -gpubnames).
Wed, Sep 5, 7:39 AM

Tue, Sep 4

labath added a comment to D51576: Enable DWARF accelerator tables by default when tuning for lldb (-glldb => -gpubnames).

We want to ensure that both Apple and DWARF5 tables never get generated though. That would waste a lot of space. I would say if DWARF5 tables are enabled, then we need ensure we disable Apple tables.

Tue, Sep 4, 11:32 AM
labath added a comment to D51576: Enable DWARF accelerator tables by default when tuning for lldb (-glldb => -gpubnames).

This is DWARF5+ only, right? (We shouldn't change the preference of Apple accelerator tables for DWARF 4 and earlier).

Tue, Sep 4, 11:20 AM

Mon, Sep 3

labath accepted D51420: [DebugInfo] Have the verifier accept missing linkage name for anything other than subprograms..

looks good to me

Mon, Sep 3, 2:59 AM

Sun, Sep 2

labath created D51576: Enable DWARF accelerator tables by default when tuning for lldb (-glldb => -gpubnames).
Sun, Sep 2, 3:34 AM

Sat, Sep 1

labath accepted D51208: [DWARF] Fix dwarf5-index-is-used.cpp.

As for the original patch, which we've kind of hijacked, I think it is a good idea to commit this for now.

Sat, Sep 1, 8:12 AM · Restricted Project
labath added a comment to D51208: [DWARF] Fix dwarf5-index-is-used.cpp.

But if LLDB has different performance characteristics, or the default should be different for other reasons - I'm fine with that. I think I left it on for Apple so as not to mess with their stuff because of the MachO/dsym sort of thing that's a bit different from the environments I'm looking at.

These are the numbers from my llvm-dev email in June:

setting a breakpoint on a non-existing function without the use of
accelerator tables:
real 0m5.554s
user 0m43.764s
sys 0m6.748s

setting a breakpoint on a non-existing function with accelerator tables:
real 0m3.517s
user 0m3.136s
sys 0m0.376s

This is an extreme case,

What was being tested here? Is it a realistic case (ie: not a pathalogical case with an absurd number of symbols, etc)? Using ELF? Fission or not?

Sat, Sep 1, 8:06 AM · Restricted Project
labath committed rLLDB341274: Ignore unicode decode errors in test suite's encoded_file class.
Ignore unicode decode errors in test suite's encoded_file class
Sat, Sep 1, 5:17 AM
labath committed rL341274: Ignore unicode decode errors in test suite's encoded_file class.
Ignore unicode decode errors in test suite's encoded_file class
Sat, Sep 1, 5:17 AM
labath added a comment to D51557: Replace uses of LazyBool with LazyBool template.

I've been wanting to implement something like this for a long time, so thank you for working on this. :)

Sat, Sep 1, 4:44 AM

Fri, Aug 31

labath committed rL341235: Avoid using short identifiers in some tests.
Avoid using short identifiers in some tests
Fri, Aug 31, 11:26 AM
labath committed rLLDB341235: Avoid using short identifiers in some tests.
Avoid using short identifiers in some tests
Fri, Aug 31, 11:26 AM
labath committed rLLDB341186: XFail one more VSCode test which fails under heavy load.
XFail one more VSCode test which fails under heavy load
Fri, Aug 31, 1:32 AM
labath committed rL341186: XFail one more VSCode test which fails under heavy load.
XFail one more VSCode test which fails under heavy load
Fri, Aug 31, 1:32 AM

Thu, Aug 30

labath committed rL341167: Fix a typo in mac SIP workaround.
Fix a typo in mac SIP workaround
Thu, Aug 30, 11:02 PM
labath committed rLLDB341167: Fix a typo in mac SIP workaround.
Fix a typo in mac SIP workaround
Thu, Aug 30, 11:02 PM
labath committed rL341164: Increase qHostInfo packet timeout.
Increase qHostInfo packet timeout
Thu, Aug 30, 10:35 PM
labath committed rLLDB341164: Increase qHostInfo packet timeout.
Increase qHostInfo packet timeout
Thu, Aug 30, 10:35 PM
labath committed rL341163: Silence some "control reaches end of non-void function" warnings with gcc.
Silence some "control reaches end of non-void function" warnings with gcc
Thu, Aug 30, 10:19 PM
labath committed rLLDB341163: Silence some "control reaches end of non-void function" warnings with gcc.
Silence some "control reaches end of non-void function" warnings with gcc
Thu, Aug 30, 10:19 PM
labath committed rL341096: Fix deadlock in gdb-client tests.
Fix deadlock in gdb-client tests
Thu, Aug 30, 12:15 PM
labath committed rLLDB341096: Fix deadlock in gdb-client tests.
Fix deadlock in gdb-client tests
Thu, Aug 30, 12:15 PM
labath added a comment to D50384: Move Predicate.h from Host to Utility.

Also, to answer Zachary's question:

Thu, Aug 30, 9:06 AM

Wed, Aug 29

labath added a comment to D50384: Move Predicate.h from Host to Utility.

Not blocked on anything, just haven't gotten around to committing it yet. Feel free to land it for me.

Wed, Aug 29, 11:04 PM
labath added a comment to D51420: [DebugInfo] Have the verifier accept missing linkage name for anything other than subprograms..

You are correct that we were being too strict in our requirements here. Though if these structs do have linkage names they could actually be useful (eg as a substitute for the "qualified name hash" in lldb) and we could consider adding them as an extension.

Wed, Aug 29, 7:05 AM

Tue, Aug 28

labath committed rL340841: Respect platform sysroot when loading core files.
Respect platform sysroot when loading core files
Tue, Aug 28, 9:35 AM
labath committed rLLDB340841: Respect platform sysroot when loading core files.
Respect platform sysroot when loading core files
Tue, Aug 28, 9:34 AM
labath committed rL340826: Clarify comment in the string-offsets-table-order.ll test.
Clarify comment in the string-offsets-table-order.ll test
Tue, Aug 28, 7:47 AM

Aug 25 2018

labath updated subscribers of D51208: [DWARF] Fix dwarf5-index-is-used.cpp.

As far as the strict intention of this test goes, the change is fine, as it is meant to check that the accelerator tables get used *when* they are generated. How do you achieve them being generated is not important.

However, I am not sure now under what circumstances will the accelerator tables be emitted in the first place. David, does this mean that we will now not emit .debug-names even if one specifies -glldb? Was that intentional?

Not especially intentional - but I clearly didn't give it quite enough thought. Mostly I was modelling the behavior of GCC (no pubnames by default - you can opt-in to them (& split-dwarf opts in by default, but one thing GCC didn't do was allow them to be turned off again - which is what I wanted)).

As for the default behavior for DWARFv5 - have you run much in the way of performance numbers on how much debug_names speeds things up? From what I could see with a gdb-index (sort of like debug_names - but linker generated, so it's a single table for the whole program) it didn't seem to take GDB long to parse/build up its own index compared to using the one in the file. So it seemed to me like the extra link time, object size, etc, wasn't worth it in the normal case. The really bad case for me is split-DWARF (worse with a distributed filesystem) - where the debugger has to read all the .dwo files & might have a high latency filesystem for each file it reads... super slow. But if the debug info was either in the executable (not split) or in a DWP (split then packaged), it seemed pretty brief.

But if LLDB has different performance characteristics, or the default should be different for other reasons - I'm fine with that. I think I left it on for Apple so as not to mess with their stuff because of the MachO/dsym sort of thing that's a bit different from the environments I'm looking at.

Aug 25 2018, 1:05 PM · Restricted Project
labath added inline comments to D49685: LLDB does not respect platform sysroot when loading core on Linux.
Aug 25 2018, 12:41 PM

Aug 24 2018

labath added a comment to D51208: [DWARF] Fix dwarf5-index-is-used.cpp.

As far as the strict intention of this test goes, the change is fine, as it is meant to check that the accelerator tables get used *when* they are generated. How do you achieve them being generated is not important.

Aug 24 2018, 6:28 AM · Restricted Project
labath added inline comments to D50213: DebugInfo: Add metadata support for disabling DWARF pub sections.
Aug 24 2018, 6:20 AM

Aug 22 2018

labath accepted D50298: Add unit test for StringLexer.

This is another one of classes we should probably get rid of (it looks like all of this functionality is available in StringRef), but while we have it, it might as well be tested.

Aug 22 2018, 12:03 PM

Aug 21 2018

labath accepted D49685: LLDB does not respect platform sysroot when loading core on Linux.

Thank you for writing the test. This is more-or-less what I had in mind. Just make sure we don't put the test files in /tmp (e.g., because windows doesn't have it).

Aug 21 2018, 12:09 PM

Aug 15 2018

labath accepted D50716: [Support] Add a basic C API for llvm::Error..

I am not sure my LGTM is enough, but in any case, it looks good to me.

Aug 15 2018, 11:05 AM

Aug 14 2018

labath added a comment to D50599: [VERY-WIP] [ItaniumDemangle] Add ability to re-serialize the parsed AST .

That's an interesting idea. The slight hickup I see is that for my use case, I only need to update C1->C2 for the top-level function (and not, e.g. for the C1 instances nested inside local names). This kind of thing is easy to do on the AST, but not from within the parseCtorDtor() function. I suspect that may be true for other transformations as well (I'm not sure if there is a good spec of what should exactly be substituted by D50586, but I think this could be an issue there too). I suppose that could be made to work by overriding parseLocalName (and anything else that may embed a function encoding), but it won't be ideal, because we would need to duplicate some of the parsing logic:

disableC1substitution();
Node *Encoding = parseEncoding();
enableC1substitution();
if (consumeIf('s'))
  // do stuff
 
if (consumeIf('d'))
  // do other stuff
 
Node *Entity = parseName(State);
...

Or we could just not support substitution in local names (I think LLDB has bigger problems when working with local objects than missing constructors).

Couldn't you just track the <encoding> depth by overriding parseEncoding, and only do the analysis in parseCtorDtor for top-level encodings?

Aug 14 2018, 10:05 AM
labath added a comment to D50681: Remove manual byte counting from internal Stream methods..

What would you say to moving this class to the header, so that it can be used in all the other byte-counting patches too?

Aug 14 2018, 9:45 AM
labath accepted D50676: Remove manual byte counting from Highlighter code..

cool

Aug 14 2018, 9:41 AM
labath added a comment to D50716: [Support] Add a basic C API for llvm::Error..

It seems to me this will not handle multi-error objects correctly, but I don't know much about your use case to know whether that is an issue or not.

Aug 14 2018, 9:37 AM

Aug 13 2018

labath added a comment to D50599: [VERY-WIP] [ItaniumDemangle] Add ability to re-serialize the parsed AST .

This is really cool, thanks for putting this together! In order to properly recreate the mangled name, we would have to track a far amount more information in the AST, looks like you have a pretty good start. I think that the set of transformations that we could support here would be pretty limited. For instance, substituting int for int* in a mangled name is probably a non-starter because we would have to add a substitution, which means that we would have to track substitutions from the AST (in order to tell when int* already appeared in the mangled name and should be remangled as a substitution), and adjust future substitutions numbers, which sounds like it would be hard to get right. Just replacing one <builtin-type> for another should be fine though (since those can't be substitutions), as should the constructor thing you mentioned.

Aug 13 2018, 12:27 PM
labath added a comment to D50586: [Demangle] Add itaniumFindTypesInMangledName().

Doing things this way, would require adding more hooks to the demangler, which does not seem particularly nice. OTOH, exposing the AST would allow other interesting uses too. ...

Yes, I am totally with you. Doing this on an exposed AST adds lots of potential, but it also seems like a bigger functional change to me, which requires proper planning and feature discussions. Thus, I am in favour of doing things step by step here. I'd first mimic the old LLDB behaviour with the new demangler and remove FastDemangle from LLDB. Afterwards we can plan and discuss at which places and for which extended functionality we can make use of an exposed AST.

In the meantime, I think llvm::itaniumFindTypesInMangledName() even adds value on its own as it's a simple way to visit parameter types in a mangled name.

What do you think?

I think that's up to Erik mostly. Doing things this way definitely makes LLDB's life easier, but OTOH, I am generally trying to avoid cleaning up LLDB by pushing the mess into LLVM. This is not a particularly large mess, but it still a very odd specialized api that will only ever be used by a single customer.

Aug 13 2018, 6:26 AM

Aug 11 2018

labath added a comment to D50586: [Demangle] Add itaniumFindTypesInMangledName().

I've recently ran into another case where I've needed to modify a mangled name.

Aug 11 2018, 12:32 AM

Aug 10 2018

labath created D50599: [VERY-WIP] [ItaniumDemangle] Add ability to re-serialize the parsed AST .
Aug 10 2018, 11:36 PM
labath added inline comments to D50525: [WIP] Move lldb-mi interpreter tests to LIT.
Aug 10 2018, 1:35 AM
labath added a comment to D49739: Add new API to SBTarget class.

I think those options don't fit. I'm looking for behavior like this:

~/workspace/gsoc/build/bin/lldb-server gdbserver --pipe 1 localhost:0
36251

Here lldb-server prints out the port number it is listening on and continues running.

If debugserver can choose a tcp port in case of passed hostname:0 then probably all we need to do is to add analogue of --pipe option.

Aug 10 2018, 1:11 AM

Aug 8 2018

labath added a comment to D50365: Add a new tool named "lldb-vscode" that implements the Visual Studio Code Debug Adaptor Protocol.

To end things on a positive note: I think the test coverage is pretty good (I'm sure somebody will suggest switching to lit), and I think a VS code plugin would be a great addition to lldb.

Aug 8 2018, 8:15 AM
labath accepted D50071: Use rich mangling information in Symtab::InitNameIndexes().

I think this looks great. I am very happy with the final result. Thank you for your patience, and thanks again for taking on this task.

Aug 8 2018, 6:28 AM
labath added inline comments to D50071: Use rich mangling information in Symtab::InitNameIndexes().
Aug 8 2018, 2:53 AM
labath edited reviewers for D50365: Add a new tool named "lldb-vscode" that implements the Visual Studio Code Debug Adaptor Protocol, added: zturner, davide; removed: labath.

I am not sure I'll have the resources to see this review through, so I'd prefer to leave this to someone else.

Aug 8 2018, 2:42 AM
labath added a comment to D50213: DebugInfo: Add metadata support for disabling DWARF pub sections.

Actually - potentially we could merge the accelerator table options into this too, to promote them to an IR feature as well. But it looks like they aren't really supported on a per-CU basis, but are across the whole compilation only. (read the spec of debug_names - I see, best to emit the widest entry possible (ie: bad idea to emit one table per CU if we're emitting multiple CUs in a single object file (LTO) - and no need not to emit it if it's been requested, I suppose - though I guess a user might reasonably request no accelerator table for /some/ CUs they expect not to debug much/are OK with the debugger indexing slowly later on if they do)). But Apple's names don't support multiple CUs at all, so they can't be unified there anyway.

Aug 8 2018, 1:49 AM
labath updated the diff for D50384: Move Predicate.h from Host to Utility.

Updating the module map too (thanks).

Aug 8 2018, 1:30 AM

Aug 7 2018

labath added inline comments to D50071: Use rich mangling information in Symtab::InitNameIndexes().
Aug 7 2018, 12:48 PM
labath added a comment to D50198: [lldbsuite, windows] Mark tests as XFAIL on Windows or skip them.

BTW, since we switched to the lit test runner, the expectedFlakey decorators don't actually do anything.

Oh, haha, that explains why it made no difference. Should we remove the expectedFlakey decorators entirely, so that they don't confuse anyone else (and replace them with a comment) or is there a plan to make them work again in the future?

Aug 7 2018, 6:20 AM
labath committed rLLDB339136: Move ScalarTest to follow the class being tested.
Move ScalarTest to follow the class being tested
Aug 7 2018, 6:11 AM
labath committed rL339136: Move ScalarTest to follow the class being tested.
Move ScalarTest to follow the class being tested
Aug 7 2018, 6:10 AM
labath created D50384: Move Predicate.h from Host to Utility.
Aug 7 2018, 5:58 AM
labath created D50383: Move SafeMachO from Utility to Host.
Aug 7 2018, 5:56 AM
labath committed rL339130: Fix a couple of extended-offsetof warnings that had slipped through.
Fix a couple of extended-offsetof warnings that had slipped through
Aug 7 2018, 5:17 AM
labath committed rLLDB339130: Fix a couple of extended-offsetof warnings that had slipped through.
Fix a couple of extended-offsetof warnings that had slipped through
Aug 7 2018, 5:17 AM
labath committed rLLDB339127: Move RegisterValue,Scalar,State from Core to Utility.
Move RegisterValue,Scalar,State from Core to Utility
Aug 7 2018, 4:09 AM