Page MenuHomePhabricator
Feed Advanced Search

Thu, Apr 18

probinson added a comment to D58033: Add option for emitting dbg info for call site parameters.

@probinson @aprantl Thanks a lot for your comments!

Let's clarify some things. I'm sorry about the confusion.

Initial patch for the functionality can be restricted by this option (like we pushed here), since LLDB doesn't read this type of debug info (yet).
The plan is, when LLDB has all necessary info and we are sure that everything works fine during using this info in debugging sessions, we can turn it to ON by default.

Does that make sense ? :)

Thu, Apr 18, 7:36 AM · debug-info

Tue, Apr 16

probinson added inline comments to D60382: FileCheck [2/12]: Stricter parsing of -D option.
Tue, Apr 16, 8:51 AM · Restricted Project
probinson added a comment to D58033: Add option for emitting dbg info for call site parameters.

I guess I'm not clear what your final goal is for the option. Keep it, even though GCC doesn't have one like it? Eliminate it? Please clearly state what you intend to have in the end, and what you might have in the short term in case that is different.

Tue, Apr 16, 8:45 AM · debug-info
probinson added a comment to D60382: FileCheck [2/12]: Stricter parsing of -D option.

Therefore, if we want to remove the diagnostic from that function we need to remove the ability to define a numeric variable from a numeric expression (which allows stuff like -D#NUMVAR1=10 -D#NUMVAR2=NUMVAR1+4. How useful do you think this ability is?

Tue, Apr 16, 7:32 AM · Restricted Project
probinson added a comment to D59687: [DebugInfo] Prologue inserter need to insert DW_OP_deref_size.

The Chromium compilation segfault comes down to two issues:

  1. DW_OP_deref_size is supposed to take a single byte argument (and not a ULEB128). If a size argument larger than 127 was used ULEB128 does not encode the same way as data1 so the extractor in DwarfDebug::emitDebugLocEntry looses track and that results in the crash.
Tue, Apr 16, 7:23 AM · Restricted Project, debug-info

Fri, Apr 12

probinson added a comment to D60382: FileCheck [2/12]: Stricter parsing of -D option.

Wouldn't it be preferable to put the command-line option validation in the driver, rather than here?
The division of responsibilities between the driver and the library is really not clear-cut; normally I'd expect the driver to do option parsing/validation and the library to simply accept the list. (I understand that FileCheck currently isn't always organized that way, but it's something I'd like to see happen.)

If the library was only used by the FileCheck executable I would agree but since it is used as a library by some of the tests I believe it makes sense to test here. Some of the code could go away if the library was receiving global defines as a vector of pair of StringRef but the validation of variable name would still be necessary IMO.

Fri, Apr 12, 9:30 AM · Restricted Project
probinson added inline comments to D60383: FileCheck [3/12]: Stricter parsing of @LINE expressions.
Fri, Apr 12, 6:32 AM · Restricted Project
probinson added a comment to D60382: FileCheck [2/12]: Stricter parsing of -D option.

Wouldn't it be preferable to put the command-line option validation in the driver, rather than here?
The division of responsibilities between the driver and the library is really not clear-cut; normally I'd expect the driver to do option parsing/validation and the library to simply accept the list. (I understand that FileCheck currently isn't always organized that way, but it's something I'd like to see happen.)

Fri, Apr 12, 6:20 AM · Restricted Project
probinson added inline comments to D60381: FileCheck [1/12]: Move variable table in new object.
Fri, Apr 12, 5:51 AM · Restricted Project

Thu, Apr 11

probinson added a comment to D54327: Adding debug info to support Fortran (part 3).

Thanks, Paul. I can certainly file a bug after this lands for tracking purposes.

Process question: should this review be updated with the bug information/link?

Yes, please post the url for the bug after you file it. You don't need to mention it in the commit log for the patch though.

Thu, Apr 11, 12:19 PM · Restricted Project, debug-info

Sun, Apr 7

probinson added inline comments to D59347: [DebugInfo] Combine Trivial and NonTrivial flags.
Sun, Apr 7, 7:25 AM · Restricted Project, Restricted Project
probinson updated subscribers of D60364: [DWARF] Set discriminator to 0 for DW_LNS_copy.

+Dehao who I believe did the discriminator work in the first place.

Sun, Apr 7, 6:55 AM · Restricted Project

Wed, Apr 3

probinson added a comment to D54327: Adding debug info to support Fortran (part 3).

Thanks, Paul. I can certainly file a bug after this lands for tracking purposes.

Process question: should this review be updated with the bug information/link?

Wed, Apr 3, 1:16 PM · Restricted Project, debug-info
probinson added a comment to D54327: Adding debug info to support Fortran (part 3).

Regarding your LTO-like experiments, that result is more or less what I thought would happen. In a normal compilation, each CU gets its own description of the types, and the fact that they are different in different CUs doesn't matter. Within each CU's context, the common-block description is complete and will be used correctly by the debugger.
In LTO, however, the IR linker wants to de-duplicate debug information, to avoid multiple copies of the same type in the final object file. I suspect that de-duplication (which IIRC is founded on the C++ "one definition rule") probably should not apply to Fortran, or at least not to common blocks.
This is not something you need to solve today, but I think after this lands, you should file a bug to the effect that LTO with Fortran can produce incorrect debug information, specifically for common blocks. That will at least keep track of this factoid somewhere that we can find it again.

Wed, Apr 3, 2:28 AM · Restricted Project, debug-info
probinson added a comment to D54114: Adding debug info to support Fortran (part 2).

Sorry for being late to the party... I'm probably repeating some other comments but wanted to get these thoughts down.
Existing DI should handle an array with compile-time-constant bounds, so would not need anything new.
Variable-bound arrays are available in a variety of languages, not excepting C (VLAs). Again I'd have thought that existing DI would be able to handle this case, although I'm less sure of that.
DWARF did add a bunch of stuff for the newer Fortran array features, I'll have to re-acquaint myself with those before commenting.

Wed, Apr 3, 1:45 AM · Restricted Project, debug-info

Fri, Mar 29

probinson accepted D59815: [Driver] Enable -fsanitize-address-globals-dead-stripping by default on PS4..

LGTM

Fri, Mar 29, 7:13 AM · Restricted Project

Thu, Mar 28

probinson accepted D59923: [Driver] Simplify -g level computation and its interaction with -gsplit-dwarf.

LGTM. I wish it had occurred to me to pass both OPT_g_Group and OPT_gsplit_dwarf to the same getLastArgs call in the first place.

Thu, Mar 28, 9:07 AM · Restricted Project, Restricted Project
probinson added a comment to D59923: [Driver] Simplify -g level computation and its interaction with -gsplit-dwarf.

Commentary questions.

Thu, Mar 28, 6:54 AM · Restricted Project, Restricted Project
probinson added a comment to D59553: [LLD][ELF][DebugInfo] llvm-symbolizer shows incorrect source line info if --gc-sections used.

I think at this point the "debug info cabal" is more in favor of fragmenting the DWARF emitted by the compiler, so that it can be gc'd in tandem with the related functions. That solution costs extra relocations and extra sections in the .o file, but uses all existing mechanisms in the linker to achieve the goal.

Thu, Mar 28, 4:43 AM · lld, Restricted Project
probinson added a comment to D59687: [DebugInfo] Prologue inserter need to insert DW_OP_deref_size.

Aside from one style nit, I'm okay with this if Adrian is.

Thu, Mar 28, 4:11 AM · Restricted Project, debug-info

Wed, Mar 27

probinson added a comment to D59347: [DebugInfo] Combine Trivial and NonTrivial flags.

@asmith: Where's the LLVM-side change/review that goes with this, btw?

As a rule I would prefer flags with positive names, as it's slightly easier to read !isTrivial than !isNonTrivial. And trivially shorter. :-)

Fair enough - I was mostly coming at this from the "the patch that was committed should be reverted" & then we could haggle over other things, but fair point.

Hmm, one other thought: Technically "non trivial" is perhaps more accurate/less error prone. Only marking structures as "trivial" but other types without that marker makes it more subtle (since not all trivial types would be marked trivial - only those of a classification that means they /could/ be non-trivial). Whereas marking the non-trivial types is more broadly accurate.

Wed, Mar 27, 11:36 AM · Restricted Project, Restricted Project

Tue, Mar 26

probinson added a comment to D59518: [DwarfDebug] Skip entries to big for 16 bit size field in Dwarf < 5..

Out of curiosity, because I can't quite spot it - where is this part of debug_loc defined in DWARFv4? I don't see any mention of a location description being prepended by its length there - but I'm guessing I'm misreading/missing it in there somewhere.

Tue, Mar 26, 9:39 AM · Restricted Project
probinson added inline comments to D59518: [DwarfDebug] Skip entries to big for 16 bit size field in Dwarf < 5..
Tue, Mar 26, 8:21 AM · Restricted Project
probinson added a comment to D59347: [DebugInfo] Combine Trivial and NonTrivial flags.

As a rule I would prefer flags with positive names, as it's slightly easier to read !isTrivial than !isNonTrivial. And trivially shorter. :-)

Tue, Mar 26, 7:25 AM · Restricted Project, Restricted Project
probinson added a comment to D59008: [AMDGPU] Switch default dwarf version to 5.

LGTM

Do we know the state of split DWARF and DWARF compression for DWARF 5 (compared to DWARF 2)?

State of them in what sense? Compression is pretty orthogonal to any DWARF version - it's more about the container (ELF, etc) you use. Split DWARF is non-standardly supported in pre-v5, and I think it's functioning in the standards conformant v5 mode too.

I had heard mention that at least split DWARF may not be fully supported yet for DWARF 5 in LLVM. But maybe that is old news:-)

Might be - nothing I know of right now. (type units aren't fully supported in DWARFv5 - but that's the only big thing on my list)

Tue, Mar 26, 7:21 AM · Restricted Project
probinson added a comment to D59815: [Driver] Enable -fsanitize-address-globals-dead-stripping by default on PS4..

This is fine for PS4, I'm just curious whether anyone knows if there's a predicate that means something like "target does not use GNU tools" so we don't have to itemize Fuschia and PS4 this way.

Tue, Mar 26, 5:22 AM · Restricted Project
probinson added a comment to D59687: [DebugInfo] Prologue inserter need to insert DW_OP_deref_size.

Thanks for the detailed explanation. The deref_size is clearly necessary in this example.
Most DWARF expressions are location expressions, not value expressions, so most deref operations are actually fetching an address. As we start doing more with salvaging values from optimizations, we might find ourselves doing more value expressions, so it's worth keeping an eye out for those. The call-site parameter stuff might be a place to think about in those terms.

Tue, Mar 26, 4:12 AM · Restricted Project, debug-info

Mon, Mar 25

probinson added a comment to D57694: [DebugInfo][DAG] Either salvage dangling debug info or emit Undef DBG_VALUEs.

Switching it to a MapVector makes it deterministic. I was just struggling late last night to try to reduce the .ll file down to something worth checking in! If you want to take over to minimize the test case, that would be much appreciated. Let me know so I can continue doing that if needed. Thanks.

Hmm, what kind of requirements are there for tests for nondeterminism? Just a high probability of triggering the existing fault/variation? This is interesting as unreliable compilation presumably means the test can't be reliable either.

Mon, Mar 25, 9:01 AM · Restricted Project
probinson added inline comments to D59687: [DebugInfo] Prologue inserter need to insert DW_OP_deref_size.
Mon, Mar 25, 8:25 AM · Restricted Project, debug-info

Fri, Mar 22

probinson accepted D59515: [llvm] Prevent duplicate files in debug line header in dwarf 5..

A couple more style nits and LGTM.

Fri, Mar 22, 4:06 AM · debug-info, Restricted Project
probinson added a comment to D59553: [LLD][ELF][DebugInfo] llvm-symbolizer shows incorrect source line info if --gc-sections used.

@jhenderson and I did a prototype of DWARF-unit-per-function last year, and I was not favorably impressed by the numbers. But maybe he still has the actual data kicking around somewhere. We did not solve all the issues to our satisfaction before we ran out of time.
I've also had chats with @bd1976llvm about fragmenting .debug_info per-function without wrapping everything in units; you get into requiring some section-order things but it saves the unit-per-function overhead.

This is pretty much what I was talking about. You definitely don't need to do it as units if you're just including the concrete function. FWIW this is what I was talking about in the dwarf meeting where we talked about bringing units back into debug_info :)

Fri, Mar 22, 3:57 AM · lld, Restricted Project

Thu, Mar 21

probinson added a comment to D59515: [llvm] Prevent duplicate files in debug line header in dwarf 5..

Thanks for working on this! I knew I had left duplications behind, but the task to take care of them hadn't ever gotten to the top of the list.
Mostly style things to start with.

Thu, Mar 21, 7:45 AM · debug-info, Restricted Project
probinson added a comment to D59553: [LLD][ELF][DebugInfo] llvm-symbolizer shows incorrect source line info if --gc-sections used.

This is straying far enough from the original review that maybe a dev thread is a better place to discuss "how to strip per-function debug info along with the functions."

Thu, Mar 21, 4:30 AM · lld, Restricted Project
probinson added a comment to D59553: [LLD][ELF][DebugInfo] llvm-symbolizer shows incorrect source line info if --gc-sections used.

@jhenderson and I did a prototype of DWARF-unit-per-function last year, and I was not favorably impressed by the numbers. But maybe he still has the actual data kicking around somewhere. We did not solve all the issues to our satisfaction before we ran out of time.
I've also had chats with @bd1976llvm about fragmenting .debug_info per-function without wrapping everything in units; you get into requiring some section-order things but it saves the unit-per-function overhead.

Thu, Mar 21, 4:29 AM · lld, Restricted Project

Mar 20 2019

probinson added a comment to D59553: [LLD][ELF][DebugInfo] llvm-symbolizer shows incorrect source line info if --gc-sections used.

Does this do the right thing for a 32-bit target? 64-bit is common, but not universal.

Mar 20 2019, 12:53 PM · lld, Restricted Project
probinson added a comment to D59562: [SymbolFileDWARF] Introduce DWARFContext.

I remember LLVM's DWARFContext being irritating to deal with when I was doing the DWARF 5 stuff. The exact details have been swapped out of my memory, but I suspect it had something to do with needing to know whether I was in DWO mode or normal mode in order to snag the right section for some sort of cross-section lookup. This is because DWARFContext is the dumping ground for all the sections, regardless of what kind of file we're looking at, and it's up to the user of its interfaces to know what mode it's in.
I will admit that having one dumping ground is convenient in some ways, especially when we were looking at object files that contained a mix of both normal and .dwo sections, but IIRC we don't emit mixed-mode object files anymore.

Mar 20 2019, 4:22 AM · Restricted Project
probinson added a comment to D59518: [DwarfDebug] Skip entries to big for 16 bit size field in Dwarf < 5..

Filed PR41152 for the unobvious display of a zero-length location expression.

Mar 20 2019, 4:02 AM · Restricted Project

Mar 19 2019

probinson accepted D59518: [DwarfDebug] Skip entries to big for 16 bit size field in Dwarf < 5..

LGTM

Mar 19 2019, 12:23 PM · Restricted Project
probinson added a comment to D59518: [DwarfDebug] Skip entries to big for 16 bit size field in Dwarf < 5..
Mar 19 2019, 8:25 AM · Restricted Project
probinson added a comment to D59518: [DwarfDebug] Skip entries to big for 16 bit size field in Dwarf < 5..

Generating the test on the fly with Python seems plausible. Note you don't need 16K components, just enough components to make the location description exceed 16K bytes. If each component is (say) a 64-bit field with a max-int constant value, that's something like 11 bytes of description per field, so ~1500 fields ought to do it.

Mar 19 2019, 5:51 AM · Restricted Project

Mar 18 2019

probinson added a comment to D59417: [GVN] Add default debug location when constructing PHI nodes.
In D59417#1433403, @vsk wrote:
In D59417#1431369, @vsk wrote:

As for instructions at the start of the block - I'm pretty sure that a while back @probinson made a change to ensure that cascade locations couldn't occur at the start of a block (that we'd set to line zero down in the AsmPrinter/DwarfDebug if that occurred) so we shouldn't end up with super weird/layout-based cascade locations for instructions generated from phis at the start of blocks.

That makes sense. What if a block has multiple phis? I.e. if the first phi in a block has a location but the second phi doesn't, is that a bug, or do we expect the location to cascade?

Locations cascade, with one exception: If the first instruction after a label does not have an explicit source location, we emit line 0.

That sounds like a sensible rule. Presumably that line 0 location has the correct scope set. Shall I relax the debugify verifier so that it only diagnoses non-phi instructions without locations? I.e. are phis special in some way, or would the relaxed check still be too strict (& any 'no location' diagnostic could be noisy)?

Mar 18 2019, 11:13 AM · Restricted Project

Mar 15 2019

probinson added a comment to D59417: [GVN] Add default debug location when constructing PHI nodes.
In D59417#1431369, @vsk wrote:

As for instructions at the start of the block - I'm pretty sure that a while back @probinson made a change to ensure that cascade locations couldn't occur at the start of a block (that we'd set to line zero down in the AsmPrinter/DwarfDebug if that occurred) so we shouldn't end up with super weird/layout-based cascade locations for instructions generated from phis at the start of blocks.

That makes sense. What if a block has multiple phis? I.e. if the first phi in a block has a location but the second phi doesn't, is that a bug, or do we expect the location to cascade?

Mar 15 2019, 2:43 PM · Restricted Project
probinson added a comment to D59417: [GVN] Add default debug location when constructing PHI nodes.

Aren't phis *always* at the start of a block?
If that's the case, I'm tempted to say phis should be allowed to have no source location, and we should fix the debugify verifier accordingly. Sometimes a phi does have an appropriate source location, which is fine. I supposed sometimes a phi ought to have a real location, but doesn't, and the verifier will stop helping us to find those cases; but it will save a bit of memory not to attach source locations to every phi in the world, and have no practical effect on the final line table (because those will turn into line-0 anyway).

Mar 15 2019, 11:59 AM · Restricted Project
probinson added a comment to D59417: [GVN] Add default debug location when constructing PHI nodes.

I believe this is a patch to fix PR37964?

Mar 15 2019, 10:28 AM · Restricted Project

Mar 14 2019

probinson committed rG96c1f2cd6c82: Tighten up tests that use -debugify as a shortcut. NFC (authored by probinson).
Tighten up tests that use -debugify as a shortcut. NFC
Mar 14 2019, 4:09 PM
probinson committed rL356217: Tighten up tests that use -debugify as a shortcut. NFC.
Tighten up tests that use -debugify as a shortcut. NFC
Mar 14 2019, 4:08 PM
probinson added a comment to D59347: [DebugInfo] Combine Trivial and NonTrivial flags.

I'd preserve the trivial test cases and show that the NonTrivial flag is *not* present. I can suggest ways to achieve this if you like (note there is no CHECK-DAG-NOT combined directive).

Mar 14 2019, 5:30 AM · Restricted Project, Restricted Project

Mar 13 2019

probinson added inline comments to D59288: [DebugInfoMetadata] Move main subprogram DIFlag into DISPFlags.
Mar 13 2019, 11:38 AM · Restricted Project

Mar 12 2019

probinson added a comment to D59235: Remove Support for DWARF64.

My main concern with the LLVM DWARF parser is all of the asserts in the code. If you attempt to use a DWARFDIE without first checking it for validity, it will crash on you instead of returning a good error or default value. That makes me really nervous as we shouldn't just crash the debugger. The switching over won't be too hard, just the fallout from the LLDB versions of the class that do error checking and return good error/default values and LLVM being very strict.

Sure, I'm prepared to deal all that appropriately. I don't plan to regress LLDB's stability in the process.

That's why for now I'm just doing very small preliminary steps to get the two interfaces to be closer to each other and simplify the problem space. We can worry about the asserts and all of that when we actually start moving pieces of LLDB to use LLVM's classes (which isn't in this patch).

Mar 12 2019, 8:01 AM · Restricted Project
probinson accepted D58784: [FileCheck]Remove assertions that prevent matching an empty string at file start before CHECK-NEXT/SAME.

I am convinced that the asserts are wrong, and that we currently get diags for NEXT/SAME/EMPTY at the top. So LGTM to remove the asserts.

Mar 12 2019, 6:50 AM · Restricted Project

Mar 11 2019

probinson added a comment to D58784: [FileCheck]Remove assertions that prevent matching an empty string at file start before CHECK-NEXT/SAME.

I think I can be convinced that it is ok to make an initial CHECK-NEXT match the first line of input if an explicit mention to this case is added to the existing documentation for CHECK-NEXT and perhaps also reword the current text slightly to indicate that CHECK-NEXT checks for a match in the next line of input (so that the explicit mention of CHECK-NEXT as first directive feels natural to whoever is reading).

Mar 11 2019, 5:50 AM · Restricted Project

Mar 8 2019

probinson added a comment to D54043: Adding debug info to support Fortran (part 1).

I'd be inclined to add the serialize/deserialize test to an existing test file, rather than a new test.
Similarly for the flag->attribute test.

Mar 8 2019, 9:39 AM · Restricted Project, debug-info

Mar 7 2019

probinson added a comment to D58784: [FileCheck]Remove assertions that prevent matching an empty string at file start before CHECK-NEXT/SAME.

OK sounds like we should invent a CHECK-FIRSTLINE directive. (Let's not call it CHECK-FIRST because people could think it means "do these first before other checks.") It must be the first directive, and its pattern must match on the first line of input (before the first newline).
Does that satisfy the requirements?

Mar 7 2019, 1:06 PM · Restricted Project
probinson accepted D59026: [www][GSOC2019]Add LLVM binary tools project.

I haven't verified it renders correctly, but eyeballing it, looks right.

Mar 7 2019, 9:40 AM · Restricted Project
probinson added a comment to D58952: [llvm] Skip over empty line table entries..

I'm not sure I follow this - the line table maps instructions to source locations. If there are no instructions there's nothing to map

That's the intent. However, in practice it maps instruction *addresses* to source locations.

Well, in practice it's unspecified what it means - so we can look at this and come up with different interpretations. Mine is to interpret these as half open intervals - in which case [100, 100) is empty and you keep searching, then you find [100, 104) and that contains the address you're looking for.

Mar 7 2019, 6:41 AM · debug-info, Restricted Project
probinson accepted D58451: [DebugInfo] Fix the type of the formated variable.

LGTM. It would be nice if we picked a width to print based on the width we read in, but this is fine.

Mar 7 2019, 6:20 AM · Restricted Project

Mar 6 2019

probinson added a comment to D58952: [llvm] Skip over empty line table entries..

I'm not sure I follow this - the line table maps instructions to source locations. If there are no instructions there's nothing to map

Mar 6 2019, 4:07 PM · debug-info, Restricted Project
probinson added inline comments to D58952: [llvm] Skip over empty line table entries..
Mar 6 2019, 2:59 PM · debug-info, Restricted Project
probinson added inline comments to D58952: [llvm] Skip over empty line table entries..
Mar 6 2019, 2:52 PM · debug-info, Restricted Project
probinson added inline comments to D58952: [llvm] Skip over empty line table entries..
Mar 6 2019, 2:27 PM · debug-info, Restricted Project
probinson added inline comments to D58952: [llvm] Skip over empty line table entries..
Mar 6 2019, 1:59 PM · debug-info, Restricted Project
probinson committed rG05efe0fdc472: [PS4] Emit a trap after a stack-protector fail call. (authored by probinson).
[PS4] Emit a trap after a stack-protector fail call.
Mar 6 2019, 11:58 AM
probinson committed rL355542: [PS4] Emit a trap after a stack-protector fail call..
[PS4] Emit a trap after a stack-protector fail call.
Mar 6 2019, 11:58 AM
probinson added a comment to D58784: [FileCheck]Remove assertions that prevent matching an empty string at file start before CHECK-NEXT/SAME.

I think there is value in having a way to check the very first line of input. Once we've done that, everything else ought to fall out naturally, if the model is defined well enough.

Mar 6 2019, 9:07 AM · Restricted Project

Mar 1 2019

probinson committed rGd8632c92a718: Try to fix Windows bots after r355226. (authored by probinson).
Try to fix Windows bots after r355226.
Mar 1 2019, 2:28 PM
probinson committed rL355235: Try to fix Windows bots after r355226..
Try to fix Windows bots after r355226.
Mar 1 2019, 2:27 PM
probinson committed rG1ca25763f07c: [DWARF] Make -g with empty assembler source work better. (authored by probinson).
[DWARF] Make -g with empty assembler source work better.
Mar 1 2019, 1:00 PM
probinson committed rC355226: [DWARF] Make -g with empty assembler source work better..
[DWARF] Make -g with empty assembler source work better.
Mar 1 2019, 12:59 PM
probinson committed rL355226: [DWARF] Make -g with empty assembler source work better..
[DWARF] Make -g with empty assembler source work better.
Mar 1 2019, 12:59 PM
probinson closed D58750: [DWARF] Make -g with empty assembler source work better..
Mar 1 2019, 12:59 PM · Restricted Project, debug-info
probinson added a comment to D58726: [DebugInfo][Docs] Explicitly document how dbg.value intrinsics are interpreted in optimized code.

A few wording notes. Haven't worked through the examples yet.

Mar 1 2019, 10:02 AM · Restricted Project

Feb 28 2019

probinson added a comment to D58784: [FileCheck]Remove assertions that prevent matching an empty string at file start before CHECK-NEXT/SAME.

Here's how I see it, but I realize it's subjective. If we say that an initial CHECK-SAME matches the first line, then, to be consistent with the relationship CHECK-SAME and CHECK-NEXT have everywhere else, an initial CHECK-NEXT should skip a new line and thus match the second line. That means that, in order to match consecutive lines starting with the first line, we have:

CHECK-SAME: first line
CHECK-NEXT: second line
CHECK-NEXT: third line
Feb 28 2019, 10:14 PM · Restricted Project
probinson added a comment to D58784: [FileCheck]Remove assertions that prevent matching an empty string at file start before CHECK-NEXT/SAME.

FTR, the CHECK: {{^$}} is ensuring the first line is empty? I see that CHECK-EMPTY isn't allowed as the first directive, unfortunately.

This directive looks for the next empty line, even if that's not the first line. Interestingly, when it's not the first directive, its search range starts after the previous match, so if the remainder of the previous match's line is empty (even if the full line is not empty), it'll match there.

Feb 28 2019, 5:42 PM · Restricted Project
probinson added inline comments to D58750: [DWARF] Make -g with empty assembler source work better..
Feb 28 2019, 4:04 PM · Restricted Project, debug-info
probinson updated the diff for D58750: [DWARF] Make -g with empty assembler source work better..

Address review comments & rebase.

Feb 28 2019, 2:32 PM · Restricted Project, debug-info
probinson added a comment to D58784: [FileCheck]Remove assertions that prevent matching an empty string at file start before CHECK-NEXT/SAME.

So we didn't have any tests that verified the assertion? That was an oversight.
FTR, the CHECK: {{^$}} is ensuring the first line is empty? I see that CHECK-EMPTY isn't allowed as the first directive, unfortunately.

Feb 28 2019, 12:37 PM · Restricted Project
probinson added inline comments to D58750: [DWARF] Make -g with empty assembler source work better..
Feb 28 2019, 7:38 AM · Restricted Project, debug-info

Feb 27 2019

probinson updated the summary of D58750: [DWARF] Make -g with empty assembler source work better..
Feb 27 2019, 5:27 PM · Restricted Project, debug-info
probinson created D58750: [DWARF] Make -g with empty assembler source work better..
Feb 27 2019, 5:23 PM · Restricted Project, debug-info
probinson added a comment to D58534: dsymutil support for DW_OP_convert.

Drive-by nit.

Feb 27 2019, 4:45 PM · Restricted Project, debug-info
probinson added a comment to D58726: [DebugInfo][Docs] Explicitly document how dbg.value intrinsics are interpreted in optimized code.

Some initial comments.

Feb 27 2019, 10:16 AM · Restricted Project

Feb 25 2019

probinson added a comment to D58453: [DebugInfo][CGP] Limit placeDbgValues movement of dbg.value intrinsics.

Absolutely true -- and constant-valued dbg.values (including undef, technically) are frequently the source of bug reports (ex: PR40795) as their lifetime isn't associated with anything else in the IR (see also PR40628).

Feb 25 2019, 5:25 PM · Restricted Project
probinson added a comment to D58453: [DebugInfo][CGP] Limit placeDbgValues movement of dbg.value intrinsics.

Hmmm. It appears that you are detaching the notion of here-the-value-is-computed from here-the-value-becomes-associated-with-this-variable. Usually these are concurrent in an "assignment" to the variable.
Separating these concerns means that if a value computation is hoisted, it might not be appropriate to hoist the association with the variable. That is, the "assignment" effect maybe should stay where it was, even if there's no specific instruction left in that position that implements that assignment.
I could see this situation arising in a variety of circumstances. CSE, various sorts of value-propagation (constant or not), passing a value to an inlined function parameter, yada yada.

Feb 25 2019, 12:43 PM · Restricted Project

Feb 21 2019

probinson added a comment to D57896: Variable names rule.

If I read the post correctly, it was actually agreeing with me (because it said "to reinforce your point...". Meaning that something such as lowerCaseCamel would be the third style being referred to

Correct! just acknowledging your point from a different perspective.

Feb 21 2019, 2:49 PM · Restricted Project, Restricted Project
probinson added a comment to D57896: Variable names rule.

I can't argue with anything you say.. but I guess to reinforce your point introducing what is effectively a 3rd style would likely cause even more jarring...

Feb 21 2019, 2:01 PM · Restricted Project, Restricted Project
probinson added inline comments to D58044: [DwarfDebug] Dump call site debug info into DWARF.
Feb 21 2019, 11:55 AM · debug-info
probinson added inline comments to D58044: [DwarfDebug] Dump call site debug info into DWARF.
Feb 21 2019, 11:38 AM · debug-info
probinson added inline comments to D56587: Introduce DW_OP_LLVM_convert.
Feb 21 2019, 11:31 AM · Restricted Project, debug-info
probinson added inline comments to D58035: [clang/DIVar] Emit flag for params that have unchanged values.
Feb 21 2019, 10:36 AM · debug-info
probinson added a comment to D58453: [DebugInfo][CGP] Limit placeDbgValues movement of dbg.value intrinsics.

There's a lot going on in the explanation, and partly I'm handicapped by lack of familiarity with the picky details of LLVM's location-list construction. Given all the attention to where dbg.value instructions are placed, it seems like placement is a significant factor in that construction. Intuitively, placing the dbg.value near the instruction that defines the value (assuming there is such an instruction) allows the location-list to better describe the instruction stream that is actually emitted. And, that's really what I want from a location list.
I would caution against focusing too much on the coverage statistics. As you say, what we really want to know is "whether the variable locations are defined over instructions in the program that make sense" and the statistics don't tell us that.
So, what instructions "make sense" in a location list? Well, the ones where the variable has an identifiable machine location or constant value. If optimization causes a value to be defined "before" the variable is declared, that does not really worry me. The goal here is to produce a correct description of the instructions-actually-emitted.
"One example problem is that conditional variable assignments can be hoisted and appear to debuggers unconditionally." Are the values actually defined unconditionally? Then it is correct to describe them that way to the debugger. I assume this is referring to PR38754. If the instructions to compute the value are hoisted, my assertion is that the location-list should describe the variable with that value when it actually occurs.
In my view, the real problem as stated in the PR appears to be that the value later gets *lost*, sadly before the instructions directly related to the switch-case where the variable is used; the real problem is *not* that the value's description starts too soon.

Feb 21 2019, 10:01 AM · Restricted Project

Feb 20 2019

probinson added a comment to D58451: [DebugInfo] Fix the type of the formated variable.

Please add a test.

Feb 20 2019, 10:37 AM · Restricted Project

Feb 13 2019

probinson updated subscribers of D56587: Introduce DW_OP_LLVM_convert.

+ @ABataev re the question whether NVPTX runs into the situation described in this review.

Feb 13 2019, 6:19 AM · Restricted Project, debug-info

Feb 12 2019

probinson added inline comments to D56587: Introduce DW_OP_LLVM_convert.
Feb 12 2019, 1:02 PM · Restricted Project, debug-info

Feb 11 2019

probinson added a comment to D56587: Introduce DW_OP_LLVM_convert.

I don't think anyone mentioned it, that's why I was bringing it up - there's always an option to not render any location if it's not possible/worth the work. That's all I was asking - is it worth the complexity? (I wasn't sure anyone needed it - but sounds like Sony does, reckon it's worth the tradeoff in complexity in LLVM compared to the work required to support this in the Sony debugger?)

Feb 11 2019, 2:19 PM · Restricted Project, debug-info
probinson added a comment to D58061: Fix a few tests that were missing ':' on CHECK lines and weren't testing anything..

There has been some progress recently on better FileCheck diagnosis of likely test-writing issues, although to date it mostly requires the human to ask "what is going on here?" explicitly. I can see adding a check to detect the missing-colon-on-otherwise-valid-directive case (including the usual suffixes), and my guess is that isn't too likely to cause excessive churn. The deeper we go into typo-detection the more likely we are to trip over false positives, but this small step seems like a worthy change.
Happy to review such a patch, or somebody can file a PR and CC me.

Feb 11 2019, 12:25 PM · Restricted Project
probinson added a comment to D56587: Introduce DW_OP_LLVM_convert.

How should DW_OP_convert be handled when targeting DWARF versions earlier than 5? There is the GNU extension DW_OP_GNU_convert, which GDB seems to have had support for since 2011. The operation seems to be the identical to the final version that got into DWARFv5, so LLDB should be able to handle the two variants transparently. Can we emit that GNU extension (under some limitations)?

That seems fine for debugger-tuning=gdb (and eventually lldb once we implemented support for it). Is emitting the byzantine shift/mask expression that this review started with in all other cases an option for a reasonably large subset of the uses?

If we have something nice for GDB and LLDB, and Paul's OK with one of those for Sony's stuff - then who would we be maintaining this extra code for? I'd be OK saying that backwards/sidewards/unspecified compatibility might not be worth it? If someone comes with a need, it could be resurrected/implemented - and until then, we could emit no location at all, potentially.

Feb 11 2019, 11:31 AM · Restricted Project, debug-info

Feb 8 2019

probinson added a comment to D56587: Introduce DW_OP_LLVM_convert.

How should DW_OP_convert be handled when targeting DWARF versions earlier than 5? There is the GNU extension DW_OP_GNU_convert, which GDB seems to have had support for since 2011. The operation seems to be the identical to the final version that got into DWARFv5, so LLDB should be able to handle the two variants transparently. Can we emit that GNU extension (under some limitations)?

Feb 8 2019, 7:36 AM · Restricted Project, debug-info

Feb 7 2019

Herald added a project to D57896: Variable names rule: Restricted Project.
  1. It might be best to give this more visibility, by submitting a mail to llvm-dev, with a noticeable subject, like "RFC: changing variable naming rules in LLVM codebase"
Feb 7 2019, 10:14 AM · Restricted Project, Restricted Project
probinson closed D57333: Initial GSOC 2019 project.

r353328. (Typo'd the link in the commit message.)

Feb 7 2019, 9:34 AM

Feb 6 2019

probinson committed rL353328: Add a "-g causes no codegen change" project for GSOC 2019..
Add a "-g causes no codegen change" project for GSOC 2019.
Feb 6 2019, 11:19 AM