Page MenuHomePhabricator
Feed Advanced Search

Today

dblaikie committed rG2f51176223f1: Reapply: "DebugInfo: Emit only one kind of accelerated access/name table"" (authored by dblaikie).
Reapply: "DebugInfo: Emit only one kind of accelerated access/name table""
Tue, Apr 23, 11:59 AM
dblaikie committed rL359026: Reapply: "DebugInfo: Emit only one kind of accelerated access/name table"".
Reapply: "DebugInfo: Emit only one kind of accelerated access/name table""
Tue, Apr 23, 11:58 AM
dblaikie committed rGa2470a465317: Revert "DebugInfo: Emit only one kind of accelerated access/name table" (authored by dblaikie).
Revert "DebugInfo: Emit only one kind of accelerated access/name table"
Tue, Apr 23, 8:02 AM
dblaikie committed rL358997: Revert "DebugInfo: Emit only one kind of accelerated access/name table".
Revert "DebugInfo: Emit only one kind of accelerated access/name table"
Tue, Apr 23, 8:01 AM

Yesterday

dblaikie added a comment to D60955: [llvm] Remove final and add default virtual dtor to CommandLine parsers.

This seems to reversing r231221 which devirtualized this. What kind of customization are you envisioning? There aren't many methods here. Are you planning to override the parse method but still fall back to the base class version sometimes?

Mon, Apr 22, 4:03 PM · Restricted Project
dblaikie committed rG68602ab2f353: DebugInfo: Emit only one kind of accelerated access/name table (authored by dblaikie).
DebugInfo: Emit only one kind of accelerated access/name table
Mon, Apr 22, 3:45 PM
dblaikie committed rL358931: DebugInfo: Emit only one kind of accelerated access/name table.
DebugInfo: Emit only one kind of accelerated access/name table
Mon, Apr 22, 3:45 PM
dblaikie added inline comments to D60955: [llvm] Remove final and add default virtual dtor to CommandLine parsers.
Mon, Apr 22, 12:55 PM · Restricted Project
dblaikie accepted D60965: [llvm-mc] - Properly set the the address align field of the compressed sections..

Soundsn good to me - thanks!

Mon, Apr 22, 12:00 PM · Restricted Project

Fri, Apr 19

dblaikie committed rG07489f9ccf4a: Modules: Adopt template parameters for variable templates to set their decl… (authored by dblaikie).
Modules: Adopt template parameters for variable templates to set their decl…
Fri, Apr 19, 4:03 PM
dblaikie committed rC358796: Modules: Adopt template parameters for variable templates to set their decl….
Modules: Adopt template parameters for variable templates to set their decl…
Fri, Apr 19, 4:02 PM
dblaikie committed rL358796: Modules: Adopt template parameters for variable templates to set their decl….
Modules: Adopt template parameters for variable templates to set their decl…
Fri, Apr 19, 4:02 PM
dblaikie committed rGaa3bf6ce721d: Modules: Search for a visible definition of the decl context when computing… (authored by dblaikie).
Modules: Search for a visible definition of the decl context when computing…
Fri, Apr 19, 4:01 PM
dblaikie committed rC358795: Modules: Search for a visible definition of the decl context when computing….
Modules: Search for a visible definition of the decl context when computing…
Fri, Apr 19, 4:01 PM
dblaikie committed rL358795: Modules: Search for a visible definition of the decl context when computing….
Modules: Search for a visible definition of the decl context when computing…
Fri, Apr 19, 4:01 PM
dblaikie closed D60892: Modules: Search for a visible definition of the decl context when computing visibility of a default template parameter.
Fri, Apr 19, 4:01 PM · Restricted Project, Restricted Project

Thu, Apr 18

dblaikie created D60892: Modules: Search for a visible definition of the decl context when computing visibility of a default template parameter.
Thu, Apr 18, 3:46 PM · Restricted Project, Restricted Project
dblaikie accepted D60872: Add new warning knob for unknown attribute namespaces.

Seems pretty good to me - if you'd like to wait for more/other feedback from @rsmith or the like, that's OK too.

Thu, Apr 18, 11:39 AM
dblaikie added inline comments to D60872: Add new warning knob for unknown attribute namespaces.
Thu, Apr 18, 11:03 AM

Wed, Apr 17

dblaikie added a comment to D60470: [DWARF] Change ambiguity resolution from smallest CUOffset to largest (LowPC, CUOffset).

Ah, sorry, that's not the case I was interested in. I meant a case where two object files are linked together - one has debug info, one does not. They both have a comdat function. The non-debug info version is chosen (creating the [0, X) address range in the debug info from the other object).

If the linker makes the comdat function without debug info (assuming the debug info is not in a comdat) prevailing, the one with debug info is discarded while its debug info is kept. This is essentially the same as the --gc-sections case.

The compile unit with 0 DW_AT_low_pc is actually invalid because the addresses are incorrect. It should be ignored if it overlaps with a valid range when constructing aranges. This patch will do so.

If I understand it, this change is to the prioritization/resolution of ambiguities - but similar situations/bugs can arise when there is no ambiguity (because some code has no debug info - so it's not there to create an ambiguity). if I'm understanding/explaining correctly.

Yes, it is related to the resolution of ambiguities. The old rule is to pick the CU with the smallest E.CUOffset; the new rule is to pick the CU with the largest (E.LowPC, E.CUOffset) pair.

Wed, Apr 17, 8:24 AM · Restricted Project
dblaikie accepted D60810: [Support] Add LEB128 support to BinaryStreamReader/Writer..

Looks reasonable to me

Wed, Apr 17, 8:12 AM · Restricted Project

Tue, Apr 16

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

Looks ok - thanks!

Tue, Apr 16, 12:59 PM · Restricted Project, Restricted Project
dblaikie added a comment to D60470: [DWARF] Change ambiguity resolution from smallest CUOffset to largest (LowPC, CUOffset).

What happens if a program is linked from some objects with debug info and some objects without it?

This revision doesn't change the behavior. For the address ranges with no debug info, the results remain ??:0:0 (unknown).

Tue, Apr 16, 12:58 PM · Restricted Project
dblaikie added a comment to D60510: [ADT] Fix template parameter names of llvm::{upper|lower}_bound.

Might've made sense to separate the NFC renaming from the perfect forwarding change (& the perfect forwarding change could potentially have some matching test coverage?)

I agree, sorry about mashing them in together. That said, I was confident this wouldn't cause any trouble in practice.
What kinds of tests are you thinking about? Checking that llvm::lower_bound works on non-copyable types?

Tue, Apr 16, 11:31 AM · Restricted Project

Mon, Apr 15

dblaikie accepted D60741: Remove some more unused headers from MachineFunction.h and friends..

Sounds good to me.
How'd you test that the MachineMemOperand.h changes were OK? Looks like it doesn't have an implementation file, so I'm not sure it's included first in any file - which means it's harder to tell if removing headers from it is valid/keeps it standalone (since its inclusion context might be allowing it to get away without including necessary headers)

Mon, Apr 15, 5:23 PM · Restricted Project
dblaikie committed rGb068f92d94a5: DebugInfo: Default to standalone debug when tuning for LLDB (authored by dblaikie).
DebugInfo: Default to standalone debug when tuning for LLDB
Mon, Apr 15, 5:16 PM
dblaikie committed rC358464: DebugInfo: Default to standalone debug when tuning for LLDB.
DebugInfo: Default to standalone debug when tuning for LLDB
Mon, Apr 15, 5:14 PM
dblaikie committed rL358464: DebugInfo: Default to standalone debug when tuning for LLDB.
DebugInfo: Default to standalone debug when tuning for LLDB
Mon, Apr 15, 5:14 PM
dblaikie added a comment to D59673: [Clang] Harmonize Split DWARF options with llc.

Sure, I think the naming's a bit weird (but hard to come up with good names for any of this)

Agreed, -split-dwarf-output is pretty clear, but -split-dwarf-file could be both the actual filename or the attribute.

There is test/CodeGen/split-debug-filename.c checking that we emit !DICompileUnit({{.*}}, splitDebugFilename: "foo.dwo" into the IR under some circumstances, but I'm not sure why. It seems to be ignored by llc.

Mon, Apr 15, 2:40 PM · Restricted Project
dblaikie added a comment to D60470: [DWARF] Change ambiguity resolution from smallest CUOffset to largest (LowPC, CUOffset).

What happens if a program is linked from some objects with debug info and some objects without it?

Mon, Apr 15, 2:36 PM · Restricted Project
dblaikie added inline comments to D60445: Change cast to dyn_cast to be consistent with other casts within same scope..
Mon, Apr 15, 2:30 PM · Restricted Project
dblaikie added a comment to D60510: [ADT] Fix template parameter names of llvm::{upper|lower}_bound.

Might've made sense to separate the NFC renaming from the perfect forwarding change (& the perfect forwarding change could potentially have some matching test coverage?)

Mon, Apr 15, 11:14 AM · Restricted Project

Wed, Apr 10

dblaikie added a comment to D60470: [DWARF] Change ambiguity resolution from smallest CUOffset to largest (LowPC, CUOffset).

What does addr2line (or any other symbolizers, not that I know of others) do in these cases?

addr2line doesn't use binary search. It iterates all ELF sections, finds the first section containing the address, then iterates DWARF CUs and finds the associated line table. It has the same problem

Wed, Apr 10, 2:39 PM · Restricted Project
dblaikie updated subscribers of D59348: [DebugInfo] Combine Trivial and NonTrivial flags.
Wed, Apr 10, 2:35 PM · Restricted Project
dblaikie accepted D59347: [DebugInfo] Combine Trivial and NonTrivial flags.

Approved pending the LLVM side changes/discussion.

Wed, Apr 10, 2:32 PM · Restricted Project, Restricted Project
dblaikie added a comment to D59673: [Clang] Harmonize Split DWARF options with llc.

Ok, here is an idea. We introduce -split-dwarf-output in Clang instead of -fsplit-dwarf-dwo-name-attr. If given, it overrides the output file name for the Split DWARF file, which we otherwise take from -split-dwarf-file. The option is obviously incompatible with -enable-split-dwarf=single, so we will disallow that. This should be backwards-compatible, and bring the behavior of llc and clang -cc1 closer together. What do you think?

Wed, Apr 10, 2:28 PM · Restricted Project
dblaikie accepted D60364: [DWARF] Set discriminator to 0 for DW_LNS_copy.

Should there also be an LLVM test - given that LLVM does emit DW_LNS_copy by the looks of it, and if it's been being incorrectly interpreted/dumped, then that seems to imply there's some missing LLVM test coverage for that case, maybe?

Do you mean a test of lib/MC/MCDwarf.cpp? As I understand it, lib/DebugInfo/DWARF is mostly the reader part and MC the writer part. With my casual reading, MCDwarf.cpp seems to do the correct thing by doing Discriminator = 0;. I haven't looked into that part yet but I can investigate that and add a test if needed in a separate change.

Wed, Apr 10, 2:24 PM · Restricted Project
dblaikie added a comment to D59923: [Driver] Simplify -g level computation and its interaction with -gsplit-dwarf.

is that to imply that the first block all do not use split DWARF?

The first block do not use split DWARF.

Wed, Apr 10, 2:03 PM · Restricted Project, Restricted Project

Tue, Apr 9

dblaikie added a comment to D59923: [Driver] Simplify -g level computation and its interaction with -gsplit-dwarf.

I'm still not entirely clear on how this is all changing, sorry - in the patch description summary, the first block of examples doesn't mention which of those disables split DWARF (the second block of examples all say "+ split" - is that to imply that the first block all do not use split DWARF?

Tue, Apr 9, 2:27 PM · Restricted Project, Restricted Project
dblaikie added a comment to D60364: [DWARF] Set discriminator to 0 for DW_LNS_copy.

Should there also be an LLVM test - given that LLVM does emit DW_LNS_copy by the looks of it, and if it's been being incorrectly interpreted/dumped, then that seems to imply there's some missing LLVM test coverage for that case, maybe?

Tue, Apr 9, 2:13 PM · Restricted Project
dblaikie added a comment to D60470: [DWARF] Change ambiguity resolution from smallest CUOffset to largest (LowPC, CUOffset).

What does addr2line (or any other symbolizers, not that I know of others) do in these cases?

Tue, Apr 9, 2:13 PM · Restricted Project

Thu, Apr 4

dblaikie accepted D60290: NFC: Move API uses of MD5::MD5Result to Optional.

Looks good to me (:

Thu, Apr 4, 4:25 PM · Restricted Project

Tue, Apr 2

dblaikie added inline comments to D60147: [DWARF] check whether the DIE is valid before querying for information.
Tue, Apr 2, 5:27 PM · Restricted Project
dblaikie accepted D60147: [DWARF] check whether the DIE is valid before querying for information.

Looks good - thanks!

Tue, Apr 2, 5:22 PM · Restricted Project
dblaikie added inline comments to D60147: [DWARF] check whether the DIE is valid before querying for information.
Tue, Apr 2, 4:55 PM · Restricted Project
dblaikie added inline comments to D59941: [DebugInfo] Improve handling of clobbered fragments.
Tue, Apr 2, 4:41 PM · Restricted Project, debug-info
dblaikie added a comment to D59673: [Clang] Harmonize Split DWARF options with llc.

Use llvm-dwarfdump rather than llvm-objdump to dump the contents of the debug_info section and test the dwo_name there (rather than dumping hex)

I didn't know about llvm-dwarfdump, I wondered why llvm-objdump wouldn't pretty-print the debug info as objdump does. That makes a lot of sense then.

probably the objdump part of the test isn't needed?

Actually I only need to check that the DWO file is there (under the proper file name). Any ideas?

Tue, Apr 2, 4:20 PM · Restricted Project
dblaikie added inline comments to D60147: [DWARF] check whether the DIE is valid before querying for information.
Tue, Apr 2, 3:52 PM · Restricted Project
dblaikie added a comment to D60147: [DWARF] check whether the DIE is valid before querying for information.

Could you include a test case?

Tue, Apr 2, 1:12 PM · Restricted Project

Sun, Mar 31

dblaikie added inline comments to D58704: Initial (incomplete) implementation of JITLink - A replacement for RuntimeDyld..
Sun, Mar 31, 9:01 AM · Restricted Project
dblaikie added a comment to D58497: Clear the KnownModules cache if the preprocessor is going away.

Ping.

Sun, Mar 31, 8:54 AM · Restricted Project

Thu, Mar 28

dblaikie added a comment to D59923: [Driver] Simplify -g level computation and its interaction with -gsplit-dwarf.

What's the general motivation for this work/changes?

The current -gsplit-dwarf handling is a bit complex and the motivation is to make it less confusing.

-g0 -gsplit-dwarf => 2
-gmlt -gsplit-dwarf -fsplit-dwarf-inlining => 2
-gmlt -gsplit-dwarf -fno-split-dwarf-inlining => 1 (before) 2 (after)

It is confusing because the composition of -gmlt -gsplit-dwarf is different from -g0 -gsplit-dwarf when SplitDWARFInlining is false.

-gmlt -gsplit-dwarf -fno-split-dwarf-inlining => special: 1 (before) 2 (after)

This ^ is the only semantic change due to this refactoring?

This is the only semantic change.

There's a desire to be able to compose gmlt+gsplit-dwarf, /if/ -fno-split-dwarf-inlining is enabled. (for context, -fno-split-dwarf-inlining is the default in Google's optimized builds, since split-dwarf-inlining was never implemented in GCC & we didn't want to regress object size when switching from GCC to Clang (& no one had complained about that missing functionality))

So with -fno-split-dwarf-inlining, there's value in using gmlt with gsplit-dwarf (it reduces the size of the .dwo files - reducing the inputs/size of dwp, etc).

& it sounds like this change breaks that scenario?

Acknowledged the desire to compose -gsplit-dwarf -gmlt -fno-split-dwarf-inlining. After this patch, users should place -gmplt after -gsplit-dwarf.

In Bazel, the order of the command line options from left to right: feature flags < BUILD copts= < --copt=. So for targets specifying -g0/-gmlt in their copts / explict --copts= options, they will override -gsplit-dwarf added by the debug feature.

Thu, Mar 28, 8:42 PM · Restricted Project, Restricted Project
dblaikie requested changes to D59923: [Driver] Simplify -g level computation and its interaction with -gsplit-dwarf.

What's the general motivation for this work/changes?

Thu, Mar 28, 11:22 AM · Restricted Project, Restricted Project

Wed, Mar 27

dblaikie 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.

Wed, Mar 27, 10:50 AM · Restricted Project, Restricted Project

Tue, Mar 26

dblaikie 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.

No, it's just spectacularly hard to find. In the v4 spec this tidbit is hidden away in section 7.7.3, second paragraph. "A location list entry consists of two address offsets followed by a 2-byte length, followed by a block of contiguous bytes that contains a DWARF location description."

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

Anything having to do with section format and placement ought to be correct at this point. Certainly I see v5 type units coming out in the .debug_info section per spec, and the .dwo files look right. If there's something missing please file a bug and CC me.

There was certainly a release where split-dwarf and type units didn't work yet, but that's all done now.

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

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

Tue, Mar 26, 8:12 AM · Restricted Project, Restricted Project
dblaikie updated subscribers of D59401: Fix non-determinism in Reassociate caused by address coincidences.

@chandlerc - hey Chandler, wondering if you could take a quick look at this just to double-check it's a good way to fix and test an ABA bug (I think you're a bit more familiar with that type of bug than I am - and perhaps with Reassociate in general)

Tue, Mar 26, 8:05 AM · Restricted Project

Mon, Mar 25

dblaikie accepted D59809: [ADT] Update SmallVectorTest.EmplaceBack tests after rL356312.

Looks good - thanks!

Mon, Mar 25, 10:19 PM · Restricted Project
dblaikie accepted D59664: [llvm] Non-functional change: declared a couple of local variables as const..

Looks good - thanks!

Mon, Mar 25, 9:54 PM · Restricted Project
dblaikie added inline comments to D59664: [llvm] Non-functional change: declared a couple of local variables as const..
Mon, Mar 25, 7:07 PM · Restricted Project
dblaikie 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:-)

Mon, Mar 25, 5:04 PM · Restricted Project
dblaikie 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)?

Mon, Mar 25, 12:00 PM · Restricted Project

Mar 22 2019

dblaikie accepted D59732: [DWARF] Delete one unused DWARFContext::create overload and associated ctor of DWARFObjInMemory.

Assuming you've checked this is unused in other projects like lldb, lld, etc, sounds good to me - thanks!

Mar 22 2019, 7:22 PM · Restricted Project
dblaikie accepted D58848: [DebugInfo] follow up for "add SectionedAddress to DebugInfo interfaces".
In D58848#1440161, @avl wrote:

Please move this down at least far enough that it doesn't involve separately
computing the file name and opening the file. Where it's a "well, if you didn't
specify a section index, we'll use the first section that covers this address".

It looks like this version of patch does exactly this.
It does not open file separately and does not parse file name.
The only thing which is additionally done is for already opened file :
"well, if you didn't specify a section index, we'll use the first section that covers this address" :

uint64_t SymbolizableObjectFile::getModuleSectionIndexForAddress(

  uint64_t Address) const {
 
for (SectionRef Sec : Module->sections()) {
  if (!Sec.isText() || Sec.isVirtual())
    continue;
 
  if (Address >= Sec.getAddress() &&
      Address <= Sec.getAddress() + Sec.getSize()) {
    return Sec.getIndex();
  }
}
 
return object::SectionedAddress::UndefSection;

}

I think it looks very close to above description.

Mar 22 2019, 2:52 PM · Restricted Project
dblaikie added inline comments to D59515: [llvm] Prevent duplicate files in debug line header in dwarf 5..
Mar 22 2019, 2:23 PM · debug-info, Restricted Project
dblaikie added a comment to D58848: [DebugInfo] follow up for "add SectionedAddress to DebugInfo interfaces".
In D58848#1430203, @avl wrote:

In case Undef specified then there could be several sections with matching address ranges.
It seems to me that DWARFDebugLineTable improper place to make such a decision - which of them should be taken as a result.
This in fact high level decision, not low level.

Mar 22 2019, 11:53 AM · Restricted Project
dblaikie added inline comments to D59515: [llvm] Prevent duplicate files in debug line header in dwarf 5..
Mar 22 2019, 11:05 AM · debug-info, Restricted Project

Mar 21 2019

dblaikie added a comment to D59673: [Clang] Harmonize Split DWARF options with llc.

Pleasue include mention of the bug (PR40276) in the commit message & clarify that while this is useful for some remote compilation models, it's not strictly necessary/the only way to do it (a remote compilation model that keeps relative paths and uses compilation-dir instead can work without this attribute)

Mar 21 2019, 3:28 PM · Restricted Project

Mar 20 2019

dblaikie 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.

Re. the underlying DWARF issues:
I can't remember whether the DWARF committee has ever considered specifying a special value for "address does not exist" but I doubt it, because the DWARF spec states "If an entity has no associated machine code, none of these [address-related] attributes are specified." (DWARF v5 section 2.17, p.51.) So, the current position of the DWARF spec is that the linker is supposed to rewrite the DWARF, I guess.

Mar 20 2019, 1:20 PM · lld, Restricted Project
dblaikie updated subscribers of D59553: [LLD][ELF][DebugInfo] llvm-symbolizer shows incorrect source line info if --gc-sections used.

This seems like it might be worth a broader discussion about these sort of cases - probably llvm-dev, maybe with some DWARF folks (though the usual LLVM debug info cabal (myself, @aprantl, @probinson, @JDevlieghere, and @echristo) is probably sufficient to get a rough idea of what might be a good general approach).

Mar 20 2019, 10:37 AM · lld, Restricted Project

Mar 19 2019

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

(also the title of this patch makes it sound like this is a patch to llvm-symbolizer (which I Suspect it should be - if gold/binutils ld produce similar output to lld's current (pre-patch) output, then llvm-symbolizer should be adjusted to cope with that, even if lld is changed))

Mar 19 2019, 11:18 AM · lld, Restricted Project
dblaikie added a comment to D59553: [LLD][ELF][DebugInfo] llvm-symbolizer shows incorrect source line info if --gc-sections used.

What do other linkers (gold and gnu binutils, for instance) do in this case?

Mar 19 2019, 11:18 AM · lld, Restricted Project

Mar 15 2019

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

I believe this is a patch to fix PR37964?

Hrm - if debugify diagnoses all instances of instructions without locations as buggy, that sounds very noisy to me. How does it handle all the other cases of merged locations that end up with no location? (if my recollection is accurate and the code is still doing this - merged locations that aren't the same and that aren't calls get no location, not a zero location)

It looks like DILocation::getMergedLocation() always returns a zero location, and that Instruction::applyMergedLocation() no longer restricts itself to calls. This changed with D45396+D45397: we wanted mem2reg to set merged locations on phis to help users narrow down the scope of a crashing instruction.

Mar 15 2019, 11:40 AM · Restricted Project
dblaikie 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:58 AM · Restricted Project
dblaikie added a comment to D59417: [GVN] Add default debug location when constructing PHI nodes.

Does this need to be line zero, or could it be no location (the absence of a dbgloc)?

Mar 15 2019, 10:02 AM · Restricted Project

Mar 14 2019

dblaikie accepted D58952: [llvm] Skip over empty line table entries..

Thanks a bunch - looks good to me.

Mar 14 2019, 5:40 PM · debug-info, Restricted Project
dblaikie added a comment to D58848: [DebugInfo] follow up for "add SectionedAddress to DebugInfo interfaces".
In D58848#1430071, @avl wrote:

I moved handling Undef case from Symbolizer into SymbolizableObjectFile. Please check whether it is proper place.

Mar 14 2019, 3:39 PM · Restricted Project
dblaikie added inline comments to D58848: [DebugInfo] follow up for "add SectionedAddress to DebugInfo interfaces".
Mar 14 2019, 1:12 PM · Restricted Project
dblaikie added a comment to D58952: [llvm] Skip over empty line table entries..

Hmm, trying to stare at this function it's confusing me a fair bit. I'd expect this to be more obvious/legible than it is, but it's possible I'm just misunderstanding.

Mar 14 2019, 1:07 PM · debug-info, Restricted Project
dblaikie added inline comments to D57939: [DWARF] Refactor RelocVisitor and fix computation of SHT_RELA-typed relocation entries.
Mar 14 2019, 12:00 PM · Restricted Project
dblaikie added a comment to D58712: Changes for Installing SwiftPM for Apple Swift 5 Toolchain on PowerPC64LE.

@dblaikie, anyone you know who can help here?

Mar 14 2019, 11:15 AM · Restricted Project
dblaikie added a comment to D59347: [DebugInfo] Combine Trivial and NonTrivial flags.

Would it be simpler/better to revert all the FlagTrivial work? & use the FlagNonTrivial+composite type to imply trivial? (since FlagnonTrivial has been in-tree longer)

Mar 14 2019, 11:15 AM · Restricted Project, Restricted Project

Mar 13 2019

dblaikie added a comment to D59272: [DebugInfo] Select debug intrinsic line-numbers more carefully when promoting dbg.declare.
In D59272#1426904, @rnk wrote:

This makes me nervous. The pair of the DIVariable and DILocation is used to uniquely identify the variable that a dbg.value applies to. In practice, inlining is usually what creates multiple instances of the same variable that get updated by dbg.values. You can see how the location is used in DwarfDebug::collectVariableInfoFromMFTable.

Last time I checked, the file, line number and column of a dbg.value was completely unused. To uniquely identify and inlined instance of a variable you need to the combination of inlinedAt field of the dbg.value's DILocation and the dbg.value's DILocalVariable.

I see other places in the code that seem to assume that the scope of the location of a dbg.value will get the scope in which the variable is declared. Your change breaks that invariant. I think we could update such code to get the scope from the DIVariable, but maybe that would be wrong since it would lack inlining information.

Isn't the scope coming from the DILocalVariable though?

Mar 13 2019, 11:57 AM · Restricted Project
dblaikie added a comment to D58712: Changes for Installing SwiftPM for Apple Swift 5 Toolchain on PowerPC64LE.

Any thoughts/inputs on the possible causes?

Mar 13 2019, 11:53 AM · Restricted Project
dblaikie added inline comments to D59303: [DebugInfo] Pass all values in DebugLocEntry's constructor, NFC.
Mar 13 2019, 11:38 AM · Restricted Project, debug-info

Mar 12 2019

dblaikie accepted D58952: [llvm] Skip over empty line table entries..

Great - thanks for your patience!

Mar 12 2019, 8:15 AM · debug-info, Restricted Project
dblaikie added inline comments to D58848: [DebugInfo] follow up for "add SectionedAddress to DebugInfo interfaces".
Mar 12 2019, 8:09 AM · Restricted Project

Mar 11 2019

dblaikie added inline comments to D58848: [DebugInfo] follow up for "add SectionedAddress to DebugInfo interfaces".
Mar 11 2019, 5:48 PM · Restricted Project
dblaikie accepted D59010: [DebugInfo] Add test cases for FlagNonTrivial.

Looks good - thanks!

Mar 11 2019, 5:42 PM · Restricted Project, Restricted Project
dblaikie committed rGeae78b5157dc: Hexagon RDF: Replace function template (plus explicit specializations) with non… (authored by dblaikie).
Hexagon RDF: Replace function template (plus explicit specializations) with non…
Mar 11 2019, 4:10 PM
dblaikie committed rL355880: Hexagon RDF: Replace function template (plus explicit specializations) with non….
Hexagon RDF: Replace function template (plus explicit specializations) with non…
Mar 11 2019, 4:10 PM
dblaikie closed D58998: Replace function template (plus explicit specializations) by non-template overloads..
Mar 11 2019, 4:10 PM · Restricted Project
dblaikie added inline comments to D58952: [llvm] Skip over empty line table entries..
Mar 11 2019, 3:37 PM · debug-info, Restricted Project

Mar 9 2019

dblaikie accepted D58998: Replace function template (plus explicit specializations) by non-template overloads..

Looks good to me, thanks

Mar 9 2019, 5:13 PM · Restricted Project

Mar 8 2019

dblaikie added inline comments to D58848: [DebugInfo] follow up for "add SectionedAddress to DebugInfo interfaces".
Mar 8 2019, 2:41 PM · Restricted Project
dblaikie added inline comments to D58848: [DebugInfo] follow up for "add SectionedAddress to DebugInfo interfaces".
Mar 8 2019, 12:07 PM · Restricted Project

Mar 7 2019

dblaikie added a comment to D58998: Replace function template (plus explicit specializations) by non-template overloads..

Is there any reason this needs to be a template -- can't these just be changed to function overloads, instead of template specializations?

I'll second this - and I'm happy to take ownership (if it's needed) of the decision. This code came in with this specialization approach, and I'm going to guess it wasn't for any particularly nuanced reason & is fine to change to overloads as would be more common here.

The only reason I can think of is that we wanted to keep the overload set small (or trivial), but I don't know if that's significant. (Richard said he doesn't care either way.)

What shall we do now? Would you like to take this change and then refactor, or immediately change this to overloads?

Mar 7 2019, 1:46 PM · Restricted Project