Page MenuHomePhabricator
Feed Advanced Search

Today

dblaikie added a comment to D82728: [clang] Add -Wsuggest-override.

Glad this is generating some discussion. For my $0.02, I would also (obviously) love to be able to enable this warning on all the codebases I work on, and this patch was born out of a discussion on the C++ Slack with another user who had found this warning very useful in GCC and was wondering why Clang didn't have it yet.

The issue is that such a warning then needs to be off by default, because we can't assume the user's intent. And Clang's historically been fairly averse to off-by-default warnings due to low user-penetration (not zero, like I said, I imagine LLVM itself would use such a warning, were it implemented) & so concerns about the cost/benefit tradeoff of the added complexity (source code and runtime) of the feature.

I agree -Wsuggest-override should be off by default, yet I suspect its user-penetration will be much higher than other off-by-default warnings, due to numerous instances of people on the Internet asking for this feature, as well as the precedent for it set by GCC.

Tue, Jul 7, 12:56 AM · Restricted Project

Yesterday

dblaikie added inline comments to D79978: Call Frame Information (CFI) Handling for Basic Block Sections.
Mon, Jul 6, 8:58 PM · Restricted Project
dblaikie added a comment to D82881: [DEBUGINFO]Fix debug info for packed bitfields..

And conversely, with this patch applied, do GDB and LLDB still produce the expected result?

GDB works correctly. Did not check with lldb, but it also should work. The result is similar to the debug info, produced for the next code:

struct {
short : 3;
short : 6;
} a;
Mon, Jul 6, 8:56 PM · debug-info, Restricted Project
dblaikie added inline comments to D82367: [ObjectYAML][ELF] Add support for emitting the .debug_gnu_pubnames/pubtypes sections..
Mon, Jul 6, 8:45 PM · Restricted Project
dblaikie added a comment to D82617: Disable GCC's -Woverloaded-virtual, which has false positives..

Abandoning, we'll do this in clangd or find an acceptable way to silence it (see D82736).

Guess perhaps a different question: Why don't you want this for clangd? Does it make the codebase better by not adhering to this particular warning?

Yes, exactly. (Sorry if this wasn't explicit).

Sorry - poor phrasing on my part. Seems we disagree on this - I think it's probably a good thing to adhere to, you don't.

Yeah, I think we disagree, and that's OK! We need to stop emitting a warning, and apart from that, this doesn't seem like a terribly important question that needs an LLVM-wide policy.

On stylistic questions like this, I think code owners generally decide, right? So my intent was to drop this proposed change for clang (no consensus) and take these opinions under advisement for clangd.

I didn't re-engage here on the substance as I think all the arguments are played out and nobody's mind is being changed, and I figured it was time to move on.

I'd like to better understand the difference of opinions.

Sure, and apologies I didn't read it that way. I can summarize the counterargument as:

  1. I agree that this warning flags cases with confusing code, though in some cases (like ThreadsafeFS::view) I think the potential for confusion *due to the name-hiding + overloading pattern* is very low.
Mon, Jul 6, 6:38 PM · Restricted Project
dblaikie added inline comments to D83049: [DebugInfo] Do not hang when parsing a malformed .debug_pub* section..
Mon, Jul 6, 6:24 PM · debug-info, lld, Restricted Project
dblaikie added a comment to D82838: Parse section ranges when verifying DWARF so we can exclude addresses that should have been stripped from DWARF..

I think maybe this is sort of orthogonal to 46453... maybe not, but kind of.

Mon, Jul 6, 6:23 PM · Restricted Project
dblaikie added a comment to D82886: [DebugInfo] Fix a possible crash when reading a malformed .debug_*lists section..

Is this assertion really valuable? "length()" does the same addition that is done to create the value that length() is being compared to - it's pretty trivial? Perhaps "FullLength" should be initialized with a call to length instead of duplicating that addition?

In that case, we have a small inconsistency in the error message. In most cases, we report the full length of the data, which is the value of the unit length field plus the size of the field itself, but for the unit length of 0, we would not add the size of the field and would report only the raw value. This inconsistency is the only reason we calculate FullLength directly.

Mon, Jul 6, 6:19 PM · debug-info, Restricted Project
dblaikie added a comment to D82673: [ModuloSchedule] Make PeelingModuloScheduleExpander inheritable..

In short - the virtuality is not the issue, the inheritability is. The class can be non-virtual, no problem for us. I would like to reuse existing code in the upstream pass that is currently "private". Hence, the "protected" part is important. It also makes sense generally, because a software pipeliner on a specific subtarget may follow different expansion strategies. If you would like to revert the virtuality, no problem at all, if you keep the protected inheritance. I think we should design a better defined interface for this class in the long run. Only one target upstream and us downstream are using it AFAIK, but as we are supporting more targets, we may come up with something better. SG? Can pull in Hexagon people, yes

Mon, Jul 6, 6:06 PM · Restricted Project
dblaikie committed rG7a99aab8692c: [ModuloSchedule] Devirtualize PeelingModuloScheduleExpander::expand as it's not… (authored by dblaikie).
[ModuloSchedule] Devirtualize PeelingModuloScheduleExpander::expand as it's not…
Mon, Jul 6, 6:05 PM
dblaikie added inline comments to D83050: [DebugInfo] Add more checks to parsing .debug_pub* sections..
Mon, Jul 6, 5:59 PM · debug-info, lld, Restricted Project
dblaikie added inline comments to D82367: [ObjectYAML][ELF] Add support for emitting the .debug_gnu_pubnames/pubtypes sections..
Mon, Jul 6, 5:56 PM · Restricted Project
dblaikie added a comment to D82975: [DebugInfo] Allow GNU macro extension to be emitted.

I think if it's about compatibility(analogous behavior with GCC), existing infra is Okay/Fine(Since same encodings are used). We just need to emit the .debug_macro section with version 4 and teach the llvm-dwarfdump to parse it correctly.

One difference though is that the GNU extension does not have anything like the strx entries that LLVM currently emits: https://github.com/gcc-mirror/gcc/blob/master/include/dwarf2.h#L425, so I assume we still need code to emit the strp entries when targeting DWARF 4?

Likely - but might want to check what GCC does - maybe it uses some kind of strx encoding that's not documented, etc.

My recollection is that .debug_macro was invented independently of the strx forms so the prototype probably wouldn't have used them. Easy enough to check whether GCC's -fdebug-macro with v4 is emitting a .debug_str_offsets section.

LLVM wouldn't be using strx forms from .debug_info for v4, and would have no other reason to emit .debug_str_offsets, so I wouldn't want LLVM to use them in a v4 compatibility mode .debug_macro section either.

Mon, Jul 6, 5:53 PM · Restricted Project, debug-info
dblaikie added a comment to D82129: [DebugInfo] Drop location ranges for variables which exist entirely outside the variable's scope.

I think I didn't fully grasp that the blocks were being (tail-)merged, which makes the scope ambiguous, and all the rest. So I withdraw the objection on that basis. DWARF is fine with multiple variables pointing to the same location, but it's less forgiving about scopes IIRC, much like it can't describe multiple source attributions for an instructions. This all makes me sad, but that's how DWARF is at the moment.

Is there still an open question about whether this wants to be a cleanup pass or a verifier check? I apologize for losing track.

Mon, Jul 6, 5:44 PM · debug-info, Restricted Project
dblaikie added inline comments to D80242: [Clang] implement -fno-eliminate-unused-debug-types.
Mon, Jul 6, 1:36 PM · Restricted Project
dblaikie updated subscribers of D82975: [DebugInfo] Allow GNU macro extension to be emitted.

When you say 'by default' - do you mean by default when the user requests macro debug info (via -fdebug-macro) or by default without any extra flag?
& what does GCC do? Does it have a way to emit the standard debug_macinfo in v4 and below? Or does it always emit the debug_macro GNU extension?

I'm not particularly sure of this(introduction of GNU encodings). Behavior of GCC trunk(11.0.0) is as follows:

gcc -g3 test.c -c, after dumping using objdump(2.32), GCC will create .debug_macro(sort of it's default, until you specify -gstrict-dwarf in which case GCC will generate .debug_macinfo).

As Sourabh says this is default when not emitting strict DWARF in GCC. For Clang, my intention was for it to be enabled by default for -fdebug-macro when tuning for GDB. Maybe it would also be interesting when tuning for LLDB?

Mon, Jul 6, 1:26 PM · Restricted Project, debug-info
dblaikie added a comment to D82728: [clang] Add -Wsuggest-override.

(the presence of at least one "override" being a signal the user intended to use override and missed some [...]

I'm in favor of -Wsuggest-override, and would definitely use it if it existed.

Mon, Jul 6, 1:12 PM · Restricted Project
dblaikie added a comment to D83236: [DWARF] Add cutoff guarding validThroughout to avoid near-quadratic behaviour.

Could the algorithm be changed to do validThroughout of all variable fragments in a single pass together?

Mon, Jul 6, 12:32 PM · Restricted Project
dblaikie added a comment to D82728: [clang] Add -Wsuggest-override.

Generally Clang tries to avoid stylistic warnings like this (& they are left to be addressed by tools like clang-tidy), hence why -Winconsistent-missing-override was implemented that way (the presence of at least one "override" being a signal the user intended to use override and missed some, rather than that maybe the user hadn't intended to use it at all (because they were compiling their code with multiple versions, etc)). (but I wouldn't outright rule this out - just mentioning the general principle here, perhaps @rsmith or others have other ideas.

Mon, Jul 6, 11:51 AM · Restricted Project
dblaikie added a comment to D83084: DomTree: Remove the releaseMemory() method.

@arsenm - if you can, please include some text whenever approving a patch via phabricator, otherwise no email indicating approval is sent to the mailing lists (which makes auditing reviews difficult)

Mon, Jul 6, 11:49 AM · Restricted Project, Restricted Project
dblaikie updated subscribers of D83084: DomTree: Remove the releaseMemory() method.
Mon, Jul 6, 11:48 AM · Restricted Project, Restricted Project
dblaikie updated subscribers of D83087: DomTree: remove explicit use of DomTreeNodeBase::iterator.
Mon, Jul 6, 11:48 AM · Restricted Project, Restricted Project, Restricted Project
dblaikie updated subscribers of D83093: DomTree: Define GraphTraits for GenericDomTreeBase.
Mon, Jul 6, 11:48 AM · Restricted Project

Thu, Jul 2

dblaikie added inline comments to D83050: [DebugInfo] Add more checks to parsing .debug_pub* sections..
Thu, Jul 2, 4:13 PM · debug-info, lld, Restricted Project
dblaikie added a comment to D82673: [ModuloSchedule] Make PeelingModuloScheduleExpander inheritable..

Adding an extension point with no testing inside LLVM seems a bit problematic - is there no existing target that could use this? Or a reasonable scale of unit test that could exercise this extension point without a full-blown target?

(also this produced a warning about the fact that this type doesn't have a virtual dtor - was fixed by @jfb in c7586444ca787c3845ac4ad0bd603709f2abbb0f )

The change is basically NFC. It was made in order to allow us using the upstream pass by inheriting from it.

Thu, Jul 2, 3:41 PM · Restricted Project

Wed, Jul 1

dblaikie accepted D78851: Debug Info Support for Basic Block Sections.

Looks good - thanks!

Wed, Jul 1, 4:45 PM · Restricted Project
dblaikie added a comment to D82906: [flang][openmp] Use common Directive and Clause enum from llvm/Frontend.

Seems like this is causing a slew of compilation warnings, like:

[745/3847] Building CXX object tools/clang/lib/Sema/CMakeFiles/obj.clangSema.dir/SemaConcept.cpp.o
In file included from /usr/local/google/home/yitzhakm/remote-build/llvm-git/llvm-project/clang/lib/Sema/SemaConcept.cpp:24:
/usr/local/google/home/yitzhakm/remote-build/llvm-git/llvm-project/clang/include/clang/AST/RecursiveASTVisitor.h:2994:14: warning: enumeration values 'OMPC_inbranch', 'OMPC_link', and 'OMPC_notinbranch' not handled in switch [-Wswitch]
  switch (C->getClauseKind()) {
             ^
1 warning generated.
[766/3847] Building CXX object tools/clang/lib/Parse/CMakeFiles/obj.clangParse.dir/ParseOpenMP.cpp.o
/usr/local/google/home/yitzhakm/remote-build/llvm-git/llvm-project/clang/lib/Parse/ParseOpenMP.cpp:1689:11: warning: 19 enumeration values not handled in switch: 'OMPD_distribute_parallel_do', 'OMPD_distribute_parallel_do_simd', 'OMPD_do'
... [-Wswitch]
  switch (DKind) {
          ^
/usr/local/google/home/yitzhakm/remote-build/llvm-git/llvm-project/clang/lib/Parse/ParseOpenMP.cpp:2078:11: warning: 19 enumeration values not handled in switch: 'OMPD_distribute_parallel_do', 'OMPD_distribute_parallel_do_simd', 'OMPD_do'
... [-Wswitch]
  switch (DKind) {
          ^

Yes, sorry for that. I'm working on a fix to handle newly introduce directives/clauses. Should be ok tonight.

If a fix is going to take more than a few minutes (a few hours/the rest of the day is pretty high) could you revert this patch & recommit with the fixes?

I reverted it. Will commit back later today.

Wed, Jul 1, 4:15 PM · Restricted Project, Restricted Project, Restricted Project
dblaikie added a comment to D82906: [flang][openmp] Use common Directive and Clause enum from llvm/Frontend.

Seems like this is causing a slew of compilation warnings, like:

[745/3847] Building CXX object tools/clang/lib/Sema/CMakeFiles/obj.clangSema.dir/SemaConcept.cpp.o
In file included from /usr/local/google/home/yitzhakm/remote-build/llvm-git/llvm-project/clang/lib/Sema/SemaConcept.cpp:24:
/usr/local/google/home/yitzhakm/remote-build/llvm-git/llvm-project/clang/include/clang/AST/RecursiveASTVisitor.h:2994:14: warning: enumeration values 'OMPC_inbranch', 'OMPC_link', and 'OMPC_notinbranch' not handled in switch [-Wswitch]
  switch (C->getClauseKind()) {
             ^
1 warning generated.
[766/3847] Building CXX object tools/clang/lib/Parse/CMakeFiles/obj.clangParse.dir/ParseOpenMP.cpp.o
/usr/local/google/home/yitzhakm/remote-build/llvm-git/llvm-project/clang/lib/Parse/ParseOpenMP.cpp:1689:11: warning: 19 enumeration values not handled in switch: 'OMPD_distribute_parallel_do', 'OMPD_distribute_parallel_do_simd', 'OMPD_do'
... [-Wswitch]
  switch (DKind) {
          ^
/usr/local/google/home/yitzhakm/remote-build/llvm-git/llvm-project/clang/lib/Parse/ParseOpenMP.cpp:2078:11: warning: 19 enumeration values not handled in switch: 'OMPD_distribute_parallel_do', 'OMPD_distribute_parallel_do_simd', 'OMPD_do'
... [-Wswitch]
  switch (DKind) {
          ^

Yes, sorry for that. I'm working on a fix to handle newly introduce directives/clauses. Should be ok tonight.

Wed, Jul 1, 3:40 PM · Restricted Project, Restricted Project, Restricted Project
dblaikie accepted D82971: [DebugInfo] Refactor .debug_macro checks. NFCI.

Looks good

Wed, Jul 1, 2:04 PM · Restricted Project, debug-info
dblaikie accepted D82974: [DebugInfo] Allow GNU macro extension to be read.
Wed, Jul 1, 2:04 PM · Restricted Project, debug-info
dblaikie updated subscribers of D82266: [clang] Handle block scope when using lambda inside if initializer.

This might be marginally simpler:

Wed, Jul 1, 1:32 PM
dblaikie accepted D82972: [DebugInfo] Introduce GNU macro extension entry encodings.

looks good - please include a link to the source of these values (literally the GCC source code, or some other reference) in the commit message and maybe in a comment near the "GNU .debug_macro extension." bit.

Wed, Jul 1, 12:59 PM · Restricted Project, debug-info
dblaikie added a comment to D82975: [DebugInfo] Allow GNU macro extension to be emitted.

This patch adds the extension behind a hidden LLVM flag, -use-gnu-debug-macro. If this can be landed, I would later want to enable it by default when tuning for GDB and targeting DWARF versions earlier than 5.

Wed, Jul 1, 12:26 PM · Restricted Project, debug-info
dblaikie accepted D82828: [ELF] Don't resolve a relocation in .debug_line referencing an ICF folded symbol to the tombstone value.

@dblaikie Dave, are you ok with this change as well?

Wed, Jul 1, 11:54 AM · Restricted Project
dblaikie added a comment to D82886: [DebugInfo] Fix a possible crash when reading a malformed .debug_*lists section..

Is this assertion really valuable? "length()" does the same addition that is done to create the value that length() is being compared to - it's pretty trivial? Perhaps "FullLength" should be initialized with a call to length instead of duplicating that addition?

Wed, Jul 1, 10:48 AM · debug-info, Restricted Project
dblaikie added a comment to D82673: [ModuloSchedule] Make PeelingModuloScheduleExpander inheritable..

Adding an extension point with no testing inside LLVM seems a bit problematic - is there no existing target that could use this? Or a reasonable scale of unit test that could exercise this extension point without a full-blown target?

Wed, Jul 1, 10:15 AM · Restricted Project

Mon, Jun 29

dblaikie committed rG11cd97701746: Add missing #include (authored by dblaikie).
Add missing #include
Mon, Jun 29, 10:32 PM
dblaikie added a comment to D82834: [clang] Move a template function definition to header file.

This is already fixed in 31c689e69404bb8208de9599626f60c77b6fa81d

Mon, Jun 29, 8:56 PM
dblaikie committed rG31c689e69404: Move Sema::PragmaStack<ValueType>::Act into Sema.h so it can be instantiated as… (authored by dblaikie).
Move Sema::PragmaStack<ValueType>::Act into Sema.h so it can be instantiated as…
Mon, Jun 29, 6:35 PM
dblaikie added a comment to D82828: [ELF] Don't resolve a relocation in .debug_line referencing an ICF folded symbol to the tombstone value.

Doing this for .debug_line has a problem (https://reviews.llvm.org/D81784#2116925 )

Mon, Jun 29, 6:34 PM · Restricted Project

Sun, Jun 28

dblaikie added a comment to D82617: Disable GCC's -Woverloaded-virtual, which has false positives..

Guess perhaps a different question: Why don't you want this for clangd? Does it make the codebase better by not adhering to this particular warning?

Yes, exactly. (Sorry if this wasn't explicit).

Sun, Jun 28, 9:24 PM · Restricted Project

Fri, Jun 26

dblaikie added inline comments to D57023: [MsgPack] New MsgPackDocument class.
Fri, Jun 26, 7:03 PM · Restricted Project
dblaikie abandoned D6390: Ensure debug info for two calls to the same function from the same location are not merged.

This ended up being fixed by df706288fba670943e164893e1fa0ccda3e24895

Fri, Jun 26, 6:58 PM
dblaikie added a comment to D82617: Disable GCC's -Woverloaded-virtual, which has false positives..

FWIW, I think the example you gave is correct for GCC to warn on.

Everything the warning says is correct, but in this pattern the polymorphic usage is the whole point of the hierarchy, the subclasses are never exposed. There's no actual danger of confusion.

the derived class violates the Liskov substitution principle: it doesn't have an obj.foo(42) method.

LSP doesn't say the classes are substitutable (indeed you couldn't template over the subclasses, for example). It says that *objects* of the classes should be. And they are.

I don't think I agree with this sentiment - "template<typename T> void f(T t); int main() { base b; f(b); }" I think when it says (to quote the English formulation in the Wikipedia article) " if S is a subtype of T, then objects of type T may be replaced with objects of type S (i.e. an object of type T may be substituted with any object of a subtype S) without altering any of the desirable properties of the program"

Then replacing "base b" with "derived d" should keep working

You haven't just replaced the object type though, you've replaced the variable type too. If the variable type stays the same (say base&) and the object type changes, then we see that deriveds are valid bases, which is what LSP is asking. (Note the examples are things like covariant return types, which fit this pattern)

I'm not sure this matters - the precise definition of a particular piece of jargon doesn't imply we should draw our lines exactly there. But if we're going to cite this authority I'd like to be clear on what it claims :-)

Fri, Jun 26, 6:58 PM · Restricted Project
dblaikie added a comment to D82617: Disable GCC's -Woverloaded-virtual, which has false positives..

FWIW, I think the example you gave is correct for GCC to warn on.

Everything the warning says is correct, but in this pattern the polymorphic usage is the whole point of the hierarchy, the subclasses are never exposed. There's no actual danger of confusion.

the derived class violates the Liskov substitution principle: it doesn't have an obj.foo(42) method.

LSP doesn't say the classes are substitutable (indeed you couldn't template over the subclasses, for example). It says that *objects* of the classes should be. And they are.

Fri, Jun 26, 4:19 PM · Restricted Project
dblaikie added inline comments to D79978: Call Frame Information (CFI) Handling for Basic Block Sections.
Fri, Jun 26, 2:08 PM · Restricted Project
dblaikie added a comment to D79978: Call Frame Information (CFI) Handling for Basic Block Sections.

(don't have any particular feedback on most of the patch - CFI stuff isn't something I'm especially familiar with - just a couple of optional thoughts on simplifying/clarifying the tests)

Fri, Jun 26, 1:08 PM · Restricted Project
dblaikie added a comment to D81784: [ELF] Resolve relocations in .debug_* referencing (discarded symbols or ICF folded section symbols) to tombstone values.

Whilst merging this change into our downstream port, our private tests flagged up a behaviour difference between our old behaviour and the version this patch implements. On further investigation, I think it is a bug in the upstream patch rather than our merge or tests.

Consider the ICF case with two duplicate functions:

int foo(int x)
{
	return 42 + x;
}

int bar(int x)
{
	return 42 + x;
}

int main(){
	int x = 0;
	x += foo(x);
	x += bar(x);
	return x;
}

In this case, LLD --icf=all will result in foo and bar being combined, with foo being the "kept" function. Prior to this change, references from debug data to the folded function (i.e. bar) were updated to point at the kept function. This would of course mean there was duplicate debug data for various addresses. In general, this may not have been ideal, but in one case I think it is actually necessary, specifically in the case of .debug_line. If you run gdb on the above example, having linked it using LLD, you can set a breakpoint at lines within bar (e.g. line 8 in my example), and it will be hit both when foo is executed and when bar is executed. This is reasonable behaviour, given the debug data doesn't include call site information the debugger can use here. With this patch, the reference in .debug_line to bar is patched to -1. This means that placing a breakpoint at line 8 will result in a breakpoint at address 0x6 (in my local case), rather than in the middle of foo. This in turn means the breakpoint will never be hit. From a user's point of view, if they don't know where their function is being folded into (which would probably be the norm), the breakpoint not working properly is a serious regression. Of course, if it is placed, the program will jump to a different function than expected (and may even break unexpectedly), but I think personally that this is less confusing, especially as that is the old behaviour anyway.

I think we need to add a special case for patching .debug_line, so that duplicates are not patched to -1, but rather to the symbol they are a duplicate of (dead references should still be patched to -1). This would match our downstream's old behaviour.

Fri, Jun 26, 12:02 PM · Restricted Project
dblaikie added a comment to D82084: [DebugInfo] Refactored out `debug_line.dwo` emission from `DwarfTypeUnit` to `DwarfDebug`.

@dblaikie Are you Convinced/Okay with explanation and the overall changes.

Fri, Jun 26, 12:02 PM · debug-info, Restricted Project

Thu, Jun 25

dblaikie added a comment to D82129: [DebugInfo] Drop location ranges for variables which exist entirely outside the variable's scope.

Looking closer at COFF/register-variables.ll, it doesn't look like a bug but instead another victim of how we model debug info. Before running -branch-folder (Control Flow Optimizer) all the instructions in the else block belong to the else block scope. The branch folder merges the common tails from 'then' and 'else' into 'else', merging the debug-locations while it does so. @jmorse summarised the situation well offline: Every time we call getMergedLocation, we are creating the conditions where this occurs, and eliminating it during compilation would be a high burden.

Thu, Jun 25, 2:11 PM · debug-info, Restricted Project

Tue, Jun 23

dblaikie committed rG4935419d779b: Remove clang::Codegen::EHPadEndScope as unused (authored by dblaikie).
Remove clang::Codegen::EHPadEndScope as unused
Tue, Jun 23, 3:39 PM
dblaikie added inline comments to D57023: [MsgPack] New MsgPackDocument class.
Tue, Jun 23, 3:38 PM · Restricted Project

Mon, Jun 22

dblaikie added a comment to D82295: [IR] Short-circuit comparison with itself for Attributes.

Can this be covered in LLVM's regression tests?

Mon, Jun 22, 1:26 PM · Restricted Project

Sat, Jun 20

dblaikie added a comment to D81631: Fix undefined behavior in Dwarf..

I think memory sanitizer is buggy...

Sat, Jun 20, 2:17 PM · Restricted Project

Thu, Jun 18

dblaikie added a comment to D81631: Fix undefined behavior in Dwarf..

I can't reproduce the bug with ubsan! Even in the latest version.

Thu, Jun 18, 10:51 PM · Restricted Project
dblaikie added inline comments to D81784: [ELF] Resolve relocations in .debug_* referencing (discarded symbols or ICF folded section symbols) to tombstone values.
Thu, Jun 18, 10:20 PM · Restricted Project
dblaikie added inline comments to D80242: [Clang] implement -fno-eliminate-unused-debug-types.
Thu, Jun 18, 6:35 PM · Restricted Project
dblaikie added a comment to D81631: Fix undefined behavior in Dwarf..

Could you include a comment in the test case explaining how this IR differs from all the IR clang usually generates? (in general what's interesting about this IR)

Also - remove the "valgrind" usage from that llc invocation (test machines might not have valgrind, etc - does UBSan/ASan/MSan catch this? There are buildbots that'll run the tests with sanitizers like those enabled & it'd be good if the test could catch a regression at least on those buildbots) - and include some testing of the behavior of llc (ie: what behavior do we get instead of UB? Presumably there's some specific behavior we're expecting beyond "anything other than crashing")

This simple function is int add(int a, int b) { return a + b ;}

Thu, Jun 18, 6:03 PM · Restricted Project
dblaikie added a comment to D82129: [DebugInfo] Drop location ranges for variables which exist entirely outside the variable's scope.

Thanks for working this up/sending it out.

Thu, Jun 18, 5:31 PM · debug-info, Restricted Project
dblaikie added inline comments to D82084: [DebugInfo] Refactored out `debug_line.dwo` emission from `DwarfTypeUnit` to `DwarfDebug`.
Thu, Jun 18, 5:31 PM · debug-info, Restricted Project
dblaikie accepted D81784: [ELF] Resolve relocations in .debug_* referencing (discarded symbols or ICF folded section symbols) to tombstone values.

Some optional code layout and comments - but all good either way/whatever you find most readable/helpful.

Thu, Jun 18, 5:31 PM · Restricted Project
dblaikie added inline comments to D78851: Debug Info Support for Basic Block Sections.
Thu, Jun 18, 4:58 PM · Restricted Project
dblaikie added inline comments to D81784: [ELF] Resolve relocations in .debug_* referencing (discarded symbols or ICF folded section symbols) to tombstone values.
Thu, Jun 18, 1:06 PM · Restricted Project
dblaikie added inline comments to D82084: [DebugInfo] Refactored out `debug_line.dwo` emission from `DwarfTypeUnit` to `DwarfDebug`.
Thu, Jun 18, 1:06 PM · debug-info, Restricted Project
dblaikie added a comment to D81631: Fix undefined behavior in Dwarf..

Could you include a comment in the test case explaining how this IR differs from all the IR clang usually generates? (in general what's interesting about this IR)

Thu, Jun 18, 12:36 PM · Restricted Project
dblaikie updated subscribers of D78851: Debug Info Support for Basic Block Sections.
Thu, Jun 18, 12:34 PM · Restricted Project
dblaikie added a comment to D81319: [Dexter] Add --source-dir-root flag.

@TWeaver @jmorse It looks like both of you gave an implicit LGTM, is that correct?

I will wait one more day then submit this change so that it doesn't bit rot.

Thu, Jun 18, 10:54 AM · debug-info, Restricted Project

Wed, Jun 17

dblaikie added inline comments to D81784: [ELF] Resolve relocations in .debug_* referencing (discarded symbols or ICF folded section symbols) to tombstone values.
Wed, Jun 17, 10:13 AM · Restricted Project

Tue, Jun 16

dblaikie accepted D81844: [DebugInfo] Support parsing and dumping of DWARF64 macro units..
Tue, Jun 16, 4:00 PM · debug-info, Restricted Project
Herald updated subscribers of D81939: [deadargelim] Attach dbg info to the insert/extractvalue instructions.
Tue, Jun 16, 9:21 AM · debug-info, Restricted Project

Mon, Jun 15

dblaikie added a comment to D81732: [clang] Replace Decl::isUnconditionallyVisible() with Sema::isVisible().

Test case(s)?

Is there anything specific you have in mind?

This change should be behavior-preserving in the case where -fmodules-local-submodule-visibility isn't set, as evidenced by the existing tests, which continue to pass.

This change is a small step towards making -fmodules-local-submodule-visibility work for Objective-C, but unfortunately we're still a long way off from being able to turn this flag on; activating it for existing tests still causes them to fail because parts of AST are still using Decl::isUnconditionallyVisible() instead of Sema::isVisible(), and that's unfortunately harder to fix.

Mon, Jun 15, 11:58 PM · Restricted Project
dblaikie added inline comments to D78851: Debug Info Support for Basic Block Sections.
Mon, Jun 15, 7:51 PM · Restricted Project
dblaikie added a comment to D81631: Fix undefined behavior in Dwarf..

Is this UB codepath reached by existing test cases running in check-llvm? Or was it found on some other testing?

No. I ran my compiler which is based on LLVM with valgrind. Then this warning was popping everywhere.

Mon, Jun 15, 7:19 PM · Restricted Project
dblaikie added a comment to D74572: [BPF] preserve debuginfo types for builtin __builtin__btf_type_id().

@dblaikie I can revert but let me first understand the alternative way to do the work, at least in high level.

[
I do believe my commit message, esp. the first couple of lines is badly inaccurate. I suspect this is the one causing your confusion as well.
specially, In the beginning of commit message, I said:

u32 btf_type_id = __builtin_btf_type_id(param)

But later on, I also said:

In the above example, the second argument for __builtin_btf_type_id() is 0, which means a relocation for local adjustment, i.e., w.r.t. bpf program BTF change, will be generated. The value 1 for the second argument means a relocation for remote adjustment, e.g., against vmlinux.

The above statement implies two arguments.
The actually builtin signature should be

u32 btf_type_id = __builtin_btf_type_id(expr, reloc_type)

The first parameter is not necessary a parameter and it can be any expression.
This is my fault as this patch go through several revision and I forgot to change that. I am happy to revert and rework the commit message to make it more clear.
]

Mon, Jun 15, 5:08 PM · debug-info, Restricted Project, Restricted Project
dblaikie added a comment to D78796: [Support] Refactor LEB128 encoding into an input iterator.

Sorry for the delay coming back to this.

Mon, Jun 15, 4:35 PM · Restricted Project
dblaikie added inline comments to D81476: [DWARF5] Enable .debug_line.dwo section emission if macro info is present.
Mon, Jun 15, 4:02 PM · debug-info, Restricted Project
dblaikie updated subscribers of D79740: Align mapped_iterator::reference type with mapped_iterator::operator*() return value..

Boost documentation says the same: "If Reference is use_default then the reference member of transform_iterator is result_of<const UnaryFunction(iterator_traits<Iterator>::reference)>::type. Otherwise, reference is Reference" (https://www.boost.org/doc/libs/1_73_0/libs/iterator/doc/transform_iterator.html).

template <class UnaryFunction,
          class Iterator,
          class Reference = use_default,
          class Value = use_default>
class transform_iterator
{
public:
  typedef /* see below */ value_type;
  typedef /* see below */ reference;
...
Mon, Jun 15, 2:20 PM · Restricted Project
dblaikie added a comment to D80242: [Clang] implement -fno-eliminate-unused-debug-types.
  • fix docs (use declare consistently, avoid define)
Mon, Jun 15, 1:18 PM · Restricted Project
dblaikie requested changes to D81476: [DWARF5] Enable .debug_line.dwo section emission if macro info is present.

I think this needs a bit more work - or at least I have a few more questions.

Mon, Jun 15, 1:14 PM · debug-info, Restricted Project
dblaikie added inline comments to D81844: [DebugInfo] Support parsing and dumping of DWARF64 macro units..
Mon, Jun 15, 12:37 PM · debug-info, Restricted Project
dblaikie added a comment to D81631: Fix undefined behavior in Dwarf..

Is this UB codepath reached by existing test cases running in check-llvm? Or was it found on some other testing?

Mon, Jun 15, 12:36 PM · Restricted Project
dblaikie added a comment to D81732: [clang] Replace Decl::isUnconditionallyVisible() with Sema::isVisible().

Test case(s)?

Mon, Jun 15, 10:55 AM · Restricted Project
dblaikie added a comment to D81522: Fix variables used only in asserts..

Thanks for the fix! Totally within the realm of post-commit review so far as I can see. The paired assertions could maybe be rewritten as: "assert(MRMgr.getVarRegion(P, SFC) ->getKind()== (SFC->inTopFrame() ? NonParamVarRegionKind : ParamVarRegionKind));" though it's not necessarily better (bit verbose, but avoids the textual duplication of the getVarRegion calls). Oh, and that first assert could potentially be an "assert(llvm::all_of... " to avoid D2 being an unused variable in non-asserts builds).

Mon, Jun 15, 10:23 AM · Restricted Project

Fri, Jun 12

dblaikie committed rG5146fc15fcea: llvm-dwarfdump: Include unit count in DWP index header dumping (authored by dblaikie).
llvm-dwarfdump: Include unit count in DWP index header dumping
Fri, Jun 12, 12:41 PM
dblaikie added a comment to D81525: [Support] Ensure errs() is constructed after outs() and don't rerun tie when errs() is called.

@MaskRay sorry for turning this review thread into a mess - i was directed here but probably should rather have kept the discussions separate.

Thanks for disabling the by-default behavior for the moment. If we turn it back on then the lack of the "usual thread-safety guarantees" seems like a good thing to call out in the comments.

We did indeed turn this off in clangd explicitly, I'll leave that in in case we roll the default forward.

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

Thu, Jun 11

dblaikie added inline comments to rG030897523d43: [Support] Don't tie errs() to outs() by default.
Thu, Jun 11, 6:11 PM
dblaikie added a comment to D81156: [Support] Add stream tie function and use it for errs().

This is surprising and unsafe behaviour. Can we reconsider changing the default, at least until a more careful audit of the places errs() is used?
In particular, if errs is used from multiple threads (with a lock) and outs is used from a single thread (so no lock needed) then this introduces racy flushes to outs() concurrent with writes.

Thanks for highlighting this, it's been brought up on D81525 as well, so rather than discuss it in two places, we'll look at it there, if that's okay?

Happy to discuss there. It's a separate issue though, the discussion there is about initialization being racy,

Yeah, I realised that after posting that previous post, sorry! Still, probably best to keep the discussion in one place for now.

Did we resolve this? In an internal XLA build tsan complains about this being racy, and I'm not sure if the problem is with how we are using llvm::dbgs() or with this patch. If the latter, please rollback while we figure out a non-racy way to achieve the same thing.

Thu, Jun 11, 3:59 PM · Restricted Project
dblaikie added a comment to D81525: [Support] Ensure errs() is constructed after outs() and don't rerun tie when errs() is called.

Abandon the patch for now.

I cannot revert D81156 as at least two commits depend on it. Reverted the tie-by-default behavior in 030897523d43e3296f69d25a71a140d9e5793c6a. Hope it addresses any issue people may observe.

Thu, Jun 11, 3:59 PM · Restricted Project
dblaikie added a comment to D81525: [Support] Ensure errs() is constructed after outs() and don't rerun tie when errs() is called.

i) std streams are thread-safe by default -- one has to call sync_with_stdio(false) explicitly, and I don't think many people do. outs() is not thread safe by default.

When you say "not thread safe" you mean specifically for using outs from more than one thread at the same time, yes?

Affirmative.

I think it would be nice to have them be tied by default, though it's true that there is a fair amount of potential for breaking existing use cases

If they can still at least provide "The usual thread safety guarantees" (writing to (apparently) independent objects (errs() and outs()) does not race) then I'm not significantly opposed. If this breaks that guarantee - I don't think that's a sufficiently worthwhile tradeoff.

Unfortunately, I don't think there's a good way to provide those guarantees -- this amounts to ensuring that flush() does not race with any other stream output operation (including itself). That is probably impossible without locking, which will likely have significant implications on the stream performance.

When you say "worthwhile tradeoff", what do you mean exactly? errs() and outs() being tied by default, or the entire tieing concept in general?

Sorry, yeah - I mean tie-by-default. Essentially: Seems like this is isn't a good idea if it means that outs and errs become racy by default. I think that makes this an opt-in situation, where the app has to make the choice/provide the guarantee that it won't be writing to outs and errs from different threads.

Calling errs() << char was racy before @jhenderson's patch. raw_fd_ostream::write_impl modifies a member variable pos.

Sorry, specifically I was talking about racing between writing to outs() and writing to errs() - as far as I understand it, those did not race prior to the tying (ie: they provided the "usual thread safety guarantees" - which is that mutations of distinct objects do not race) but race once the tying was done (because a write to errs might flush outs mid-write). This is the issue @sammccall raised earlier & sounds like it actively impacts clangd.

I don't think it is actively impacting clangd. Mitigated by D81538.

Thu, Jun 11, 3:26 PM · Restricted Project
dblaikie added a comment to D81525: [Support] Ensure errs() is constructed after outs() and don't rerun tie when errs() is called.

i) std streams are thread-safe by default -- one has to call sync_with_stdio(false) explicitly, and I don't think many people do. outs() is not thread safe by default.

When you say "not thread safe" you mean specifically for using outs from more than one thread at the same time, yes?

Affirmative.

I think it would be nice to have them be tied by default, though it's true that there is a fair amount of potential for breaking existing use cases

If they can still at least provide "The usual thread safety guarantees" (writing to (apparently) independent objects (errs() and outs()) does not race) then I'm not significantly opposed. If this breaks that guarantee - I don't think that's a sufficiently worthwhile tradeoff.

Unfortunately, I don't think there's a good way to provide those guarantees -- this amounts to ensuring that flush() does not race with any other stream output operation (including itself). That is probably impossible without locking, which will likely have significant implications on the stream performance.

When you say "worthwhile tradeoff", what do you mean exactly? errs() and outs() being tied by default, or the entire tieing concept in general?

Sorry, yeah - I mean tie-by-default. Essentially: Seems like this is isn't a good idea if it means that outs and errs become racy by default. I think that makes this an opt-in situation, where the app has to make the choice/provide the guarantee that it won't be writing to outs and errs from different threads.

Calling errs() << char was racy before @jhenderson's patch. raw_fd_ostream::write_impl modifies a member variable pos.

Thu, Jun 11, 2:20 PM · Restricted Project
dblaikie added a comment to D81525: [Support] Ensure errs() is constructed after outs() and don't rerun tie when errs() is called.

i) std streams are thread-safe by default -- one has to call sync_with_stdio(false) explicitly, and I don't think many people do. outs() is not thread safe by default.

When you say "not thread safe" you mean specifically for using outs from more than one thread at the same time, yes?

Affirmative.

I think it would be nice to have them be tied by default, though it's true that there is a fair amount of potential for breaking existing use cases

If they can still at least provide "The usual thread safety guarantees" (writing to (apparently) independent objects (errs() and outs()) does not race) then I'm not significantly opposed. If this breaks that guarantee - I don't think that's a sufficiently worthwhile tradeoff.

Unfortunately, I don't think there's a good way to provide those guarantees -- this amounts to ensuring that flush() does not race with any other stream output operation (including itself). That is probably impossible without locking, which will likely have significant implications on the stream performance.

When you say "worthwhile tradeoff", what do you mean exactly? errs() and outs() being tied by default, or the entire tieing concept in general?

Thu, Jun 11, 1:14 PM · Restricted Project

Wed, Jun 10

dblaikie added a comment to D78950: Adds LRU caching of compile units in DWARFContext..

FYI, I haven't abandoned this patch. I have been waiting for more opinions including dblaikie@'s.

I'll be on leave from work for the next 6 weeks. So, once I get back from it, I'll revisit the comments then and try to figure out how to move forward.

Thank you!

Wed, Jun 10, 3:01 PM · Restricted Project, debug-info
dblaikie added a comment to D81525: [Support] Ensure errs() is constructed after outs() and don't rerun tie when errs() is called.

There's a second threadsafety issue I'd like to highlight, around runtime rather than initialization.

raw_ostreams are not threadsafe, including outs(). It's not necessarily safe to flush outs when errs() is accessed.
For example, in clangd errs() is the log stream, written by multiple threads with a lock. outs() is the protocol stream, written by the main thread without a lock.
After this change, all logging threads are trying to flush outs, racing with the main thread which is writing to it.
I can fix this in clangd but it has me questioning whether this is unsafe for other existing users and likely to go unnoticed for new ones.

Wed, Jun 10, 11:05 AM · Restricted Project

Tue, Jun 9

dblaikie added a comment to D81525: [Support] Ensure errs() is constructed after outs() and don't rerun tie when errs() is called.

Adding global ctors is generally avoided - as they add startup cost (which might be very important to interactive programs, etc) to code linking in the LLVM libraries.

Tue, Jun 9, 8:57 PM · Restricted Project
dblaikie added a comment to D59553: [WIP][LLD][ELF][DebugInfo] Use predefined value to mark debug address ranges pointing to deleted code..

(summary-ish: comdat functions that are optimized differently: subprograms must not refer to the differently optimized version
comdat functions that are optimized identically: multiple subprograms could point to the same code, but there's probably little benefit/reason to do so
identical unrelated functions: there's value in multiple subprograms pointing to the same code)

Resolving a (relocation referencing a symbol defined in a discarded COMDAT group) to the tombstone value may be more troublesome.

clang -c -ffunction-sections a.cc  # no debug info
clang -c -ffunction-sections -g b.cc

Assuming a.cc & b.cc define the same function, should the linker resolve relocations in b.o(.debug_info) to the tombstone value? Maybe not because we'll lose all debugging information.
If both a.o & b.o have debugging information, it may be reasonable to resolve relocations in b.o(.debug_info) to the tombstone value.

Tue, Jun 9, 6:48 PM · lld, Restricted Project
dblaikie added a comment to D59553: [WIP][LLD][ELF][DebugInfo] Use predefined value to mark debug address ranges pointing to deleted code..

Ah @MaskRay posted the link to the DWARF issue ( http://www.dwarfstd.org/ShowIssue.php?issue=200609.1 ) in another thread.

I'm not aware of that other thread.

In lieu of somewhere better to discuss it, just a couple of points to make, @probinson :

Currently if two inline functions are /identical/, then at least with the unix linkers I know of (bfd, gold, lld), to the best of my knowledge - the linker resolves relocations to either original copy to the final copy - so both CUs point to the same function. (with the complications as you pointed out of overlapping aranges, CU ranges, etc)
If the inline functions aren't identical, then the preserved copy is only pointed to by the DWARF that originally described it - that's important because different optimizations on the function could invalidate the DWARF (eg: one file claims the variable A is in register B, the other claims it is in register C - if both subprogram descriptions point to the final copy, one of them will be incorrect)
As for Identical Code Folding - I think it might actually be valuable to preserve that information and have both subprograms point to the same code (even with overlapping aranges/CU ranges/etc). But I could understand if that's a problem for some consumers - probably the sort of thing I'd be inclined to/hope DWARF allows, even if it suggests some implementations might choose not to take advantage of it.

(summary-ish:
comdat functions that are optimized differently: subprograms must not refer to the differently optimized versio
comdat functions that are optimized identically: multiple subprograms could point to the same code, but there's probably little benefit/reason to do so
identical unrelated functions: there's value in multiple subprograms pointing to the same code)

No dispute with any of the above. In some respects, yeah I glossed over some things or got details wrong, but the point is: There used to be more copies of a thing, now there are fewer, what is appropriate for DWARF to say about that? Allowing a more efficient way to say "not here boss" is what matters.

Tue, Jun 9, 4:37 PM · lld, Restricted Project
dblaikie added a comment to D59553: [WIP][LLD][ELF][DebugInfo] Use predefined value to mark debug address ranges pointing to deleted code..

I've filed a DWARF issue to reserve "-1" as the tombstone address value. I wrote it up such that consumers should ignore that address and any address derived from it (e.g., base+offset). I don't have the issue number for it yet, hopefully I'll remember to post it here when it's assigned.

Using -2 for .debug_loc/.debug_ranges would have to be a convention, but is entirely "legal" from a DWARF standards perspective.

Thanks so much for starting the discussion/process with the DWARF Committee! (I guess once it's got an assigned number you could link it here & we can go CC ourselves ,maybe?)

Tue, Jun 9, 2:21 PM · lld, Restricted Project
dblaikie added a comment to D59553: [WIP][LLD][ELF][DebugInfo] Use predefined value to mark debug address ranges pointing to deleted code..

I've filed a DWARF issue to reserve "-1" as the tombstone address value. I wrote it up such that consumers should ignore that address and any address derived from it (e.g., base+offset). I don't have the issue number for it yet, hopefully I'll remember to post it here when it's assigned.

Using -2 for .debug_loc/.debug_ranges would have to be a convention, but is entirely "legal" from a DWARF standards perspective.

Tue, Jun 9, 11:32 AM · lld, Restricted Project
dblaikie added a comment to D59553: [WIP][LLD][ELF][DebugInfo] Use predefined value to mark debug address ranges pointing to deleted code..
In D59553#2080495, @avl wrote:

Yeah, I just worry then it becomes another source of inconsistency between consumers/producers/etc. Perhaps we could name it in some way that's clear that it might be removed later - to encourage people to either reach out to us to explain their use case, or to invest a bit more in working with the new default behavior.

--dead-reloc-obsolete-addend

or

--dead-reloc-obsolete

? (yes/no option).

Not really sure - sometimes flags use the word "experimental" but that more sounds like it might become a real flag in the future, whereas the hope is that it's the other direction. The only other mechanism I've seen is the really verbose flag " -enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang" - but I don't think that's really necessary here. Probably "experimental" (eg: --experimental-dead-reloc (I think 'experimental' usually goes at the start - but you could check other flags for inspiration)) is enough, if we are going to have a flag at all.

How about we just go with the basic --dead-reloc-addend (or similar) with no experimental or obsolete in the name? In that case, I'd make it hidden, so users can't find it in the normal help text, and add comments both in the help text (for --help-hidden, and comments in the code) and in the release notes saying it is intended as a chicken switch for compatibility reasons, and that they should contact the LLVM community if the switch is ever actually needed, but if we don't hear we will remove it in the future.

Tue, Jun 9, 8:13 AM · lld, Restricted Project
dblaikie added a comment to D81144: [MC] Generate .debug_line in the 64-bit DWARF format [2/7].

If an assembler source contains .file/.loc directives, and -dwarf64 is given, llvm-mc will still correctly produce a DWARF64 .debug_line section. That is because the only differences between DWARF32 and DWARF64 ones are unit_length and header_length fields, and references to .debug_line_str, and all these are covered by this patch.

Do you have any specific example which results in an incorrect output with these patches?

Right, both the GenDwarf and .file/.loc paths use the same infrastructure. But if an assembler source contains .file/.loc directives, it likely also has compiler-generated .debug_info/etc sections, so the consistency of the output sections is not assured. The DWARF spec (section 7.4) states "The 32-bit and 64-bit DWARF format conventions must _not_ be intermixed within a single compilation unit."

Thinking about this more, as a practical matter, we probably don't want to make llvm-mc detect the formats of the .debug_info/etc sections and assure that all the formats are consistent. I suppose have to make it the responsibility of the user to invoke llvm-mc with --dwarf-64 only for hand-written asm or asm with other sections emitted in DWARF-64 format?

Tue, Jun 9, 8:12 AM · debug-info, Restricted Project