Page MenuHomePhabricator
Feed Advanced Search

May 9 2019

probinson created D61752: Re-enable a test for non-Windows.
May 9 2019, 12:24 PM · Restricted Project
probinson added a comment to D61611: [JITLoaderGDB] Set eTypeJIT for objects read from JIT descriptors.

@stella.stamenova I'm not familiar with any lit feature that gives a special meaning to the prefix "no". The opposite of "REQUIRES: windows" is not "REQUIRES: nowindows" but "UNSUPPORTED: windows" AFAIK.
This part of the discussion should probably be taken to llvm-dev, though.

FTR I don't see that lldb's lit.cfg.py sets any features based on host OS, so even "UNSUPPORTED: windows" probably does not work currently.

@probinson LLDB's lit configuration derives from the lit configuration in LLVM. The most important file you are looking for is:

llvm\utils\lit\lit\llvm\config.py

You can see there that we add various platform to the list of available features including system-windows, so XFAIL: system-windows, UNSUPPORTED: system-windows, etc. all work.

This is also where binary_features are set, such as 'zlib/nozlib', 'asan/not_asan' etc. The prefix varies for historical reasons, but the paradigm has existed for a long time. If we wanted to support nosystem-windows, we would add it here.

May 9 2019, 11:06 AM · Restricted Project, Restricted Project
probinson added inline comments to D61680: [X86] Avoid SFB - Fix inconsistent codegen with/without debug info .
May 9 2019, 10:07 AM · Restricted Project
probinson committed rG0b68fc3f59b5: Re-enable lit test shtest-timeout.py on non-Windows. (authored by probinson).
Re-enable lit test shtest-timeout.py on non-Windows.
May 9 2019, 10:00 AM
probinson committed rL360356: Re-enable lit test shtest-timeout.py on non-Windows..
Re-enable lit test shtest-timeout.py on non-Windows.
May 9 2019, 10:00 AM
probinson added a comment to D61611: [JITLoaderGDB] Set eTypeJIT for objects read from JIT descriptors.

@stella.stamenova I'm not familiar with any lit feature that gives a special meaning to the prefix "no". The opposite of "REQUIRES: windows" is not "REQUIRES: nowindows" but "UNSUPPORTED: windows" AFAIK.
This part of the discussion should probably be taken to llvm-dev, though.

May 9 2019, 9:46 AM · Restricted Project, Restricted Project
probinson added a comment to D61611: [JITLoaderGDB] Set eTypeJIT for objects read from JIT descriptors.

@stella.stamenova Can you have a look at the lit test please? It works on macOS and Linux, but I didn't test Windows. Should I add something like # REQUIRES: nowindows or is it fine like this?

May 9 2019, 8:13 AM · Restricted Project, Restricted Project
probinson added a comment to D60385: FileCheck [5/12]: Introduce regular numeric variables.

I am pretty happy with this now, maybe give the other people who have been participating a day or so to chime in again.

May 9 2019, 7:20 AM · Restricted Project

May 8 2019

probinson added a comment to D61445: [FileCheck] Fix code style of method comments.

Still good.

May 8 2019, 2:20 PM · Restricted Project
probinson accepted D61445: [FileCheck] Fix code style of method comments.

One or two last nits and LGTM.

May 8 2019, 11:34 AM · Restricted Project
probinson added a comment to D61680: [X86] Avoid SFB - Fix inconsistent codegen with/without debug info .

I wonder if this should be an MIR test? Fewer moving parts.

May 8 2019, 11:21 AM · Restricted Project
probinson added a comment to D61445: [FileCheck] Fix code style of method comments.

Sorry, I should have been more thorough about this previously: My understanding is that if a function description mentions any parameters with \p, then it needs to mention all of them.
For some of the one-liner descriptions, if you prefer to just remove the \p that's okay with me. You've been suffering a lot through this process and I don't want to create more work than we really need to!

May 8 2019, 9:51 AM · Restricted Project
probinson accepted D61679: [FileCheck, NFC] Split defines.txt in two.

Fix the one typo and LGTM.

May 8 2019, 9:30 AM · Restricted Project
probinson added a comment to D61680: [X86] Avoid SFB - Fix inconsistent codegen with/without debug info .

The point is not that a certain set of moves comes out, but that the *same* set of moves comes out regardless of debug info.
So, the test wants to have two copies of the same function, one with debug instructions and one without; and both functions should produce the same sequence of moves.

May 8 2019, 9:07 AM · Restricted Project
probinson requested changes to D61679: [FileCheck, NFC] Split defines.txt in two.

Aha. The new versions add the word "pattern" to some of the diagnostics, in pattern-defines-diagnostics.txt. That would be the functional change belonging to D60385, which means that test should not pass with an unmodified FileCheck? Please verify.

May 8 2019, 8:56 AM · Restricted Project
probinson added a comment to D60385: FileCheck [5/12]: Introduce regular numeric variables.

I still can't tell what the functional difference is, in pattern-defines.txt. Everything else looks fine.

There is none, pattern-defines + pattern-defines-diagnostics = old defines.txt + some new comments, as per James' comments.

May 8 2019, 5:23 AM · Restricted Project

May 7 2019

probinson added inline comments to D60385: FileCheck [5/12]: Introduce regular numeric variables.
May 7 2019, 11:01 AM · Restricted Project
probinson added a comment to D60385: FileCheck [5/12]: Introduce regular numeric variables.

I still can't tell what the functional difference is, in pattern-defines.txt. Everything else looks fine.

May 7 2019, 8:54 AM · Restricted Project
probinson added a comment to D61584: [DebugInfo] Some fields do not need relocations even relax is enabled..

Thanks for the reference, that helps some.
However I still think this isn't the right way to go about fixing the problem. This started because RISC-V decided not to resolve certain kinds of expressions, and then it turns out that applies to too many expressions. Somebody suggested that the asm backend decision should be more refined, based on symbol section perhaps, and that feels like a more principled way to go about it.

May 7 2019, 8:35 AM · Restricted Project
probinson added a comment to D61625: Debug Info: Support address space attributes on rvalue references..

+1 to Bjorn's comment.
The DWARF spec says address class is also allowed on a "subroutine or subroutine type" do we allow generating code into nonzero address spaces?

May 7 2019, 7:47 AM · Restricted Project, debug-info

May 6 2019

probinson added a comment to D60385: FileCheck [5/12]: Introduce regular numeric variables.

Nearly there! One final grammar nit and some test comments.

May 6 2019, 2:24 PM · Restricted Project
probinson committed rG1e18bfe89213: Fix more Windows bots after r360015. Depending on the environment, the… (authored by probinson).
Fix more Windows bots after r360015. Depending on the environment, the…
May 6 2019, 12:13 PM
probinson committed rL360065: Fix more Windows bots after r360015..
Fix more Windows bots after r360015.
May 6 2019, 12:10 PM
probinson added a comment to D61584: [DebugInfo] Some fields do not need relocations even relax is enabled..

I don't claim to be an MCExpr expert, but I think this should not be necessary. There are other situations where symbol differences are computed and emitted as constants, for example when DW_AT_high_pc is a length rather than an address, and they clearly don't require this tactic.

May 6 2019, 6:09 AM · Restricted Project

May 3 2019

probinson added a comment to D61496: Fixed tests where grep was not matching the linefeed.

Checked-in files should not have CRLF endings, in general (there are a very few exceptions, and these aren't among them).
If the checked-in files have LF endings but your tool checks them out with CRLF then that is a problem with your config, or with the tool.
Adding dos2unix to the RUN lines is the wrong fix, either way.

May 3 2019, 6:18 AM · Restricted Project

May 2 2019

probinson accepted D61445: [FileCheck] Fix code style of method comments.

Thanks! Some small things, and LGTM once you've fixed those.

May 2 2019, 9:39 AM · Restricted Project
probinson added inline comments to D61432: Non-8-bit bytes showcase.
May 2 2019, 8:15 AM · Restricted Project

May 1 2019

probinson added a comment to D60385: FileCheck [5/12]: Introduce regular numeric variables.

Haven't looked at the tests yet.

May 1 2019, 2:14 PM · Restricted Project
probinson accepted D60384: FileCheck [4/12]: Introduce @LINE numeric expressions.

LGTM

May 1 2019, 11:49 AM · Restricted Project
probinson added a comment to D60384: FileCheck [4/12]: Introduce @LINE numeric expressions.

Another round of commentary nits, plus a couple more substantive remarks. If you accept them all, LGTM.

May 1 2019, 9:39 AM · Restricted Project
probinson added a comment to D61187: [clangd] Move clangd tests to clangd directory. check-clangd is no longer part of check-clang-tools..

FYI, we had to disable clangd entirely after this patch, getting a weird problem with lit that we haven't figured out yet.
In case anybody else has seen something like this, and knows what's going on, please let us know.

  Running all regression tests
  llvm-lit.py: C:/j/w/opensource/opensource_to_sce_merge__2/o/llvm\utils\lit\lit\llvm\config.py:336: fatal: couldn't find 'clang' program, try setting CLANG in your environment
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppCommon.targets(171,5): error MSB6006: "cmd.exe" exited with code 2. [C:\j\w\opensource\opensource_to_sce_merge__2\build\check-all.vcxproj]
May 1 2019, 9:07 AM · Restricted Project, Restricted Project

Apr 30 2019

probinson added a comment to D60384: FileCheck [4/12]: Introduce @LINE numeric expressions.

First pass looking at docs and commentary.

Apr 30 2019, 6:07 AM · Restricted Project

Apr 26 2019

probinson added a comment to D60283: [DebugInfo] Don't emit checksums when compiling a preprocessed CPP.

Thanks Paul, your solution is even better. I'll apply rL333311 locally - if everything's fine, do you mind if I re-land it again?

Apr 26 2019, 11:49 AM · Restricted Project
probinson added a comment to D60283: [DebugInfo] Don't emit checksums when compiling a preprocessed CPP.

I had tried to do this in r333311 but some bots complained, so I reverted it and then didn't follow through. Thanks for doing this!
When I tried it, I took advantage of existing tracking of line directives at the file level, so there shouldn't be a need to add a Line flag to PresumedLoc?
What I did was something like this, in computeChecksum():

const SrcMgr::SLocEntry &Entry = SM.getSLocEntry(FID, &Invalid);
if (Invalid || !Entry.isFile() || Entry.getFile().hasLineDirectives())
  return None;
Apr 26 2019, 8:32 AM · Restricted Project

Apr 25 2019

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

I'm okay with this, but give @aprantl a chance to confirm.

Apr 25 2019, 12:41 PM · Restricted Project, debug-info
probinson added a comment to D60274: [ELF] Implement Dependent Libraries Feature.

I'm okay with the PS4-specific bits.

Apr 25 2019, 7:46 AM · Restricted Project

Apr 24 2019

probinson added inline comments to D58033: Add option for emitting dbg info for call site parameters.
Apr 24 2019, 8:04 AM · Restricted Project, debug-info
probinson accepted D60382: FileCheck [2/12]: Stricter parsing of -D option.

LGTM after the comment on the parseVariable loop is addressed.

Apr 24 2019, 7:50 AM · Restricted Project
probinson accepted D60383: FileCheck [3/12]: Stricter parsing of @LINE expressions.

LGTM

Apr 24 2019, 7:48 AM · Restricted Project
probinson added inline comments to D60382: FileCheck [2/12]: Stricter parsing of -D option.
Apr 24 2019, 7:40 AM · Restricted Project
probinson added a comment to D60831: [DebugInfo@O2][LoopVectorize] pr39024: Vectorized code linenos step through loop even after completion.

This will be my last comment on the topic and then everyone can get back to work :-). I agree with the LLVM IR requirement that one not to lie to application developers; lies are worse than nothing. However, I don't feel that you have adequately explained why attributing to any of the available (file, line) mappings for an instruction that has been merged is incorrect and not 100% reliable. Just because we can't include all contributing mappings for a merged instruction doesn't make any one unreliable; I see attributing to any one of a set of mappings as 100% correct, even though it is only partial information.

Apr 24 2019, 7:08 AM · debug-info, Restricted Project

Apr 23 2019

probinson accepted D60896: Improve error reporting for mismatched value sites in IPGO.

LGTM. The previous diagnostic would be useful only to compiler developers.

Apr 23 2019, 9:06 AM · Restricted Project

Apr 18 2019

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 ? :)

Apr 18 2019, 7:36 AM · Restricted Project, debug-info

Apr 16 2019

probinson added inline comments to D60382: FileCheck [2/12]: Stricter parsing of -D option.
Apr 16 2019, 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.

Apr 16 2019, 8:45 AM · Restricted Project, 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?

Apr 16 2019, 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.
Apr 16 2019, 7:23 AM · Restricted Project, debug-info

Apr 12 2019

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.

Apr 12 2019, 9:30 AM · Restricted Project
probinson added inline comments to D60383: FileCheck [3/12]: Stricter parsing of @LINE expressions.
Apr 12 2019, 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.)

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

Apr 11 2019

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.

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

Apr 7 2019

probinson added inline comments to D59347: [DebugInfo] Combine Trivial and NonTrivial flags.
Apr 7 2019, 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.

Apr 7 2019, 6:55 AM · Restricted Project

Apr 3 2019

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?

Apr 3 2019, 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.

Apr 3 2019, 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.

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

Mar 29 2019

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

LGTM

Mar 29 2019, 7:13 AM · Restricted Project

Mar 28 2019

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.

Mar 28 2019, 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.

Mar 28 2019, 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.

Mar 28 2019, 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.

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

Mar 27 2019

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.

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

Mar 26 2019

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.

Mar 26 2019, 9:39 AM · Restricted Project
probinson added inline comments to D59518: [DwarfDebug] Skip entries to big for 16 bit size field in Dwarf < 5..
Mar 26 2019, 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. :-)

Mar 26 2019, 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)

Mar 26 2019, 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.

Mar 26 2019, 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.

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

Mar 25 2019

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.

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

Mar 22 2019

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

A couple more style nits and LGTM.

Mar 22 2019, 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 :)

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

Mar 21 2019

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.

Mar 21 2019, 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."

Mar 21 2019, 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.

Mar 21 2019, 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