In D94882#2504207, @jhenderson wrote:

Maybe a silly suggestion (and one that would need more discussion on the mailing lists), but why not just change the default version to 5 more widely? How often do people deliberately deviate from the default DWARF version in practice? To me, the proposed change feels like a bit of a hack for what is likely fairly unusual usage, and is only temporary, since likely most toolchains will want to change to DWARF v5 at some point going forward.

(Works for me, FWIW - takes my local run down from 42 failures in check-lldb-api to 1 (a timeout))

Sounds good, thanks!

Sounds good, thanks!

"But because their source lines are outside the function source range"

Couple of optional pieces.

In D94735#2500132, @MaskRay wrote:

In D94735#2500129, @dblaikie wrote:

Ah, seems I was confused by the patch title - it looks like these values aren't used for FlagFwdDecl records - forward declarations bail out 3356, not using the file/line created on 3338/3339.

Seems like this change might lead to a situation of files but no line numbers, which seems a bit strange to me - well, at least for __va_list_tag, which isn't anymore associated with the file than with the line. Perhaps both should be addressed?

__va_list_tag is synthesized by Clang CreateX86_64ABIBuiltinVaListDecl for __builtin_va_arg. I think giving it the filename of CurLoc is fine. Giving it the line of the CurLoc is arbitrary. CurLoc may be from a very unrelated thing.

Emm.. The title was wrong. I did not read 3319 if (T && !T->isForwardDecl()) carefully...

Ah, seems I was confused by the patch title - it looks like these values aren't used for FlagFwdDecl records - forward declarations bail out 3356, not using the file/line created on 3338/3339.

In D94542#2500058, @reames wrote:

I'm not convinced that disabling these optimizations is warranted. I'm not actively opposing the patch, just want to list my concerns for the record.

As a general matter, -O3 -g means "perform optimization while preserving the best debug experience we can", not "strictly w/o reducing debug quality optimize as best as possible". We have numerous places in the optimizer that we perform optimizations that destroy debug information. We also have lots of places - one use restrictions which haven't been audited for instance - where the presence of debug info restricts optimization. We treat the later as bugs, not the former.

It's not clear to be me why this particular optimization should be disabled just because it happens to emit different code w/ and w/o debuging enabled.

The bug (https://bugs.llvm.org/show_bug.cgi?id=42138) that triggered this review appears to be an automated testing framework. I fully understand the value of that type of automatic bug discovery, but when the framework reports something which is not a bug, the framework should be fixed. I believe this is a bug in the reporting framework, not the assembler.

Bit out of my wheelhouse hopefully @rsmith or @rnk could chime in at some point.

Looks worth another go

Thanks for the pointers!

In D93510#2499262, @jplayer-nv wrote:

I just triaged the gcc 5.4 build break. It appears that std::is_trivially_copy_constructible<T> instantiates the copy constructor (which is... strange). So we can't query a compile-time property without the compiler forcing instantiation of the deleted copy constructor in this case.

This bug exists all the way up through gcc 7.3. Here's a godbolt link which reproduces the problem:
https://godbolt.org/z/ETW7f1

If we use llvm::is_trivially_copy_constructible<T> instead of std::is_trivially_copy_constructible<T>, then everything appears to be fine.

Interestingly, std::is_trivially_copy_assignable<T> appears not to instantiate the copy assignment because the compiler isn't complaining about its use. So I'm changing the OptionalStorage specialization condition to:

template <typename T, bool = (is_trivially_copy_constructible<T>::value &&
                              std::is_trivially_copy_assignable<T>::value &&
                              (std::is_trivially_move_constructible<T>::value ||
                               !std::is_move_constructible<T>::value) &&
                              (std::is_trivially_move_assignable<T>::value ||
                               !std::is_move_assignable<T>::value))>

In D94655#2498811, @MaskRay wrote:

In D94655#2498669, @dblaikie wrote:

In D94655#2498548, @MaskRay wrote:

In D94655#2498504, @dblaikie wrote:

Is there any way to condition this on the type of the output, rather than the input? (or, more specifically, on whether machine code is being generated)

Or maybe we could always pass the split-dwarf-file down through LLVM and not need to conditionalize it at all? It'd be a no-op if there's no DWARF in the IR anyway?

I tried replacing if (IRInput || Args.hasArg(options::OPT_g_Group)) { with if (1), -gsplit-dwarf may produce .dwo for regular non-g .c compile.

Are you saying that if you make that change -gsplit-dwarf does cause .dwo files to be created for non-g .c compiles? Do the dwo files have anything in them? I had modified llvm to dynamically choose split or non-split based on whether there was enough data to be worth splitting into a .dwo file, but I guess that situation might still be producing an empty .dwo file which isn't ideal - I haven't tested that.

% clang a.c -gsplit-dwarf -c
% readelf -WS a.dwo                
There are 2 section headers, starting at offset 0x50:

Section Headers:
  [Nr] Name              Type            Address          Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            0000000000000000 000000 000000 00      0   0  0
  [ 1] .strtab           STRTAB          0000000000000000 000040 000009 00      0   0  1

In D93510#2498718, @jplayer-nv wrote:

Taking a look at the gcc 5.4 failure now.

Now that the patch has been committed & reverted, do I start a new patch when fixes for identified issues are incorporated?

In D94655#2498548, @MaskRay wrote:

In D94655#2498504, @dblaikie wrote:

Is there any way to condition this on the type of the output, rather than the input? (or, more specifically, on whether machine code is being generated)

Or maybe we could always pass the split-dwarf-file down through LLVM and not need to conditionalize it at all? It'd be a no-op if there's no DWARF in the IR anyway?

I tried replacing if (IRInput || Args.hasArg(options::OPT_g_Group)) { with if (1), -gsplit-dwarf may produce .dwo for regular non-g .c compile.

In D93779#2498612, @xbolva00 wrote:

In D93779#2498509, @dblaikie wrote:

In D93779#2498501, @lebedev.ri wrote:

Why do we even want to bend over backwards and try to handle broken code correctly,
at the cost of regressed performance for everything,
instead of just adding defensive asserts against such problems,
and letting/telling the user fix the code?

I believe the standard library supports this, so I think it's a somewhat awkward limitation to have a standard-library-like container that misses that. (of course the small-mode isn't entirely compatible with std::vector, etc anyway - so some divergence is possible)

But currently the cost (compile time) is too high to be acceptable.

In D93779#2498501, @lebedev.ri wrote:

Why do we even want to bend over backwards and try to handle broken code correctly,
at the cost of regressed performance for everything,
instead of just adding defensive asserts against such problems,
and letting/telling the user fix the code?

Is there any way to condition this on the type of the output, rather than the input? (or, more specifically, on whether machine code is being generated)

Sounds good to me - but give it a day or two. @MaskRay or others might want to weigh in.

In D93781#2497219, @dexonsmith wrote:

In D93781#2470743, @dblaikie wrote:

Looks good (did you happen to try this with sanitizers without the fix applied & observe a sanitizer failure when running the updated test? Would be nice to know that's actually working as intended)

No, but just now I ran with the SmallVector.h part of this patch mostly reverted (didn't add back the assertion), and the test fails:

/Users/dexonsmith/data/github/llvm-project/working/llvm/unittests/ADT/SmallVectorTest.cpp:1139: Failure
      Expected: N
      Which is: 3
To be equal to: V.back()
      Which is: 8-byte object <01-00 00-00 00-00 00-00>
/Users/dexonsmith/data/github/llvm-project/working/llvm/unittests/ADT/SmallVectorTest.cpp:1145: Failure
      Expected: 1
To be equal to: V.back()
      Which is: 8-byte object <01-04 00-00 00-00 00-00>

The line numbers are different vs. the patch posted here because of a rebase, but this seems to confirm the test is working even without sanitizers.

About to commit (check-llvm just finished on the rebase); I can follow up with ASan post-commit if you'd like (let me know if you would).

Looks alright. I wouldn't mind knowing a bit more about how these things interact if different types of input files are listed together in a single command line, though.

In implicit thinlto this seemed to work for me without any changes:

$ clang++-tot -flto=thin test.cpp -g -c
$ clang++-tot -flto=thin -fuse-ld=lld -gsplit-dwarf test.o && llvm-dwarfdump-tot a.out
a.out:  file format elf64-x86-64

In D93779#2497131, @dexonsmith wrote:

In D93779#2497112, @dblaikie wrote:

In D93779#2497099, @dexonsmith wrote:

Reverted in 56d1ffb927d03958a7a31442596df749264a7792 due to an error on Windows:
http://lab.llvm.org:8011/#/builders/127/builds/4489/steps/7/logs/stdio
if it's obvious I'll recommit in a minute, but if anyone has ideas I'd welcome them.

Guess maybe something in the std::is_same<std::remove_const_t<std::remove_reference_t<ArgType>>, T>::value isn't working quite right on MSVC? (could test that with godbolt, maybe) - is it needed? Since it's on both insert_one_maybe_copy and there's an implementation detail/doesn't need to protect from violations of that constraint (admittedly I'm proposing removing it because maybe MSVC is violating it... )? And instead SFINAE/enable_if only on the TakesParamByValue part?

Thanks for looking; I think you're right. The constraint was a trick to allow use of SFINAE since TakesParamByValue didn't depend on the template parameter so I can't just remove it, I need a different solution...

...but I've found one, and it's a bit cleaner too. Instead of the indirection through insert_one_maybe_copy, I've added a forwarding function defined in the POD vs. non-POD base classes called forward_value_param.

I'll commit the new version once I confirm check-llvm passes locally.

In D93779#2497099, @dexonsmith wrote:

Reverted in 56d1ffb927d03958a7a31442596df749264a7792 due to an error on Windows:
http://lab.llvm.org:8011/#/builders/127/builds/4489/steps/7/logs/stdio
if it's obvious I'll recommit in a minute, but if anyone has ideas I'd welcome them.

In D80391#2497073, @MaskRay wrote:

From @dblaikie's email reply:

^ this I would consider to be a bug. -g should be needed to generate debug info into the IR, and -gsplit-dwarf should be needed to choose how debug info already in the IR should be placed into object files or dwo files.

Usually (non-LTO) these two steps are in the same compile, so -g and -gsplit-dwarf go together. But for LTO cases, I think it's suitable for -g to be needed for IR generation, and -gsplit-dwarf to be needed for object code generation, without needing -g as well in that latter step (the -g was already specified at IR generation time, and that shoul be enough).

We can see that behavior I'm describing as desirable in implicit ThinLTO I showed earlier in the thread.

I suggest this should be the desired behavior, because -g generally has no effect on IR->object code generation, so it seems strange/unnecessary to me to gate -gsplit-dwarf behind -g in that case. The -g was already specified and used during IR generation (& the -gN level, -gmlt behavior-etc has all been handled in IR generation (or embedded in the IR for use later) - so to me, specifying -g again during object code generation would be/is strange, because any special values would be ignored (-g1/g2/g3/etc would not be respected - the N value would only be respected when passed to the IR generation step))

Got it. -fthinlto-index= (thinlto backend compile) operates on bitcode files and does not IR generation. It isn't suitable for -g to be needed to use.
-gsplit-dwarf is both an IR generation option and an object file generation option. It is needed for thinlto backend compiles.

In D80391#2497018, @inglorion wrote:

For Chrome on Chrome OS, this is https://crbug.com/1158215

Here, we saw our links fail with "output file too large". Investigation revealed that debug info was being included in the binary, instead of in .dwo files as expected. That turned out to be caused by this change.

It seems that there are cases where -gsplit-dwarf is passed, but it does not take effect because there isn't also a -g (or -g<level>) option:

clang -c -fthinlto-index=foo.o.thinlto.bc -gsplit-dwarf foo.o -o foo.bin.o

Shows no .dwo file and debug info in foo.bin.o, whereas

clang -c -fthinlto-index=foo.o.thinlto.bc -gsplit-dwarf -g foo.o -o foo.bin.o

shows a .dwo file which is referenced from foo.bin.o

The only thing that is different here is that the latter command has "-g" whereas the former doesn't.

In other words, the new implementation still doesn't make -g and -gsplit-dwarf fully orthogonal; instead of -gsplit-dwarf always turning on debug fission, it *only* turns it on when there is also a -g or -g<level> option - at least in distributed ThinLTO code generation.

It seems that orthogonality was the motivation for this change, and that -gsplit-dwarf without -g is supposed to work in the linker (per MaskRay's comment about -g being ignored by the linker).

Can we make it so that -gsplit-dwarf turns on debug fission and we then use that even if no -g options were passed?

(I'm generally good with this - llvm & clang changes should be committed separately & maybe the linkage part too)

In D94639#2496923, @akhuang wrote:

In D94639#2496892, @dblaikie wrote:

What parts of this are motivated by CodeView requirements (do functions have to have unique names in CV?)?
It'd be a bit unfortunate if we have divergence in -gmlt behavior between DWARF and CodeView due to different usage requirements, rather than format requirements - gmlt in DWARF I think uses only the unqualified name, though eventually combined with -fdebug-info-for-profiling which put the mangled name on such functions to make it clear for profilers. (though the unqualified name only behavior is still handy for the sanitizers - where the unqualified/ambiguous name is a "good enough" point for size V accuracy)

This was kind of motivated by the issue in https://bugs.llvm.org/show_bug.cgi?id=48432, even though this patch doesn't solve that particular bug. I guess the general issue is that in CV the only way to make the functions unique is by their display name or type. So previously we were going in the direction of differentiating functions by the display name (like using the qualified name), but it seems like it's more size-efficient to use types instead, which is what this patch does.

What parts of this are motivated by CodeView requirements (do functions have to have unique names in CV?)?
It'd be a bit unfortunate if we have divergence in -gmlt behavior between DWARF and CodeView due to different usage requirements, rather than format requirements - gmlt in DWARF I think uses only the unqualified name, though eventually combined with -fdebug-info-for-profiling which put the mangled name on such functions to make it clear for profilers. (though the unqualified name only behavior is still handy for the sanitizers - where the unqualified/ambiguous name is a "good enough" point for size V accuracy)

Looks good, thanks!

Can you commit this yourself (do you have commit access), or do you need someone to commit it for you?

Code change looks good - test might be able to be tweaked a bit before committing.

Sounds good

I'll leave this one to @aprantl

Sounds good - thanks!

In D94063#2492450, @DavidSpickett wrote:

Do you have python enabled in the build? (https://lldb.llvm.org/resources/build.html#preliminaries)

The cmake option LLDB_ENABLE_PYTHON defaults to Auto which has tripped me up in the past. If you set it to YES then you'll get a build error if it fails to find a suitable Python instead of silently disabling it.

In D94391#2494316, @MaskRay wrote:

I removed CurLoc from call sites and tried a stage 2 build. There is such a difference:

0x00062228:   DW_TAG_structure_type
                DW_AT_calling_convention        (DW_CC_pass_by_value)
                DW_AT_name      ("__va_list_tag")
                DW_AT_byte_size (0x18)
                DW_AT_decl_file ("/home/maskray/llvm/clang/tools/driver/driver.cpp")
                DW_AT_decl_line (23)

driver.cpp:23 is a #include. So this looks strange. The DW_AT_decl_file/DW_AT_decl_line attributes are undesired due to CurLoc getLineNumber.

Sounds good

In D94391#2491229, @MaskRay wrote:

In D94391#2491178, @dblaikie wrote:

Any particular bug you're trying to fix? (this looks like it changes the debug locations, so it would need tests)

Not necessarily clear that these are better debug locations?

No particular bug. CGDebugInfo::getLineNumber returning CurLoc just looks strange. (The CurLoc may be far below (irrelevant) when getLineNumber is called.)

This patch is hopefully NFC. Dropping CurLoc from getLineNumber(RD->getLocation().isValid() ? RD->getLocation() : CurLoc) will cause a difference, which may reveal missing SourceLocation information in ObjC constructs.

Sounds OK

Seems OK - I don't know if there's a nicer way to handle the latter cases that need the 1 + ~N.

Do you need to run the destructor before placement new in these situations?

In D94494#2493719, @dblaikie wrote:

In D94494#2492801, @markus wrote:

bbi-51646.ll1 KBDownload

The issue was found with attached input bbi-51646.ll If necessary it could be added as a regression test but then the question is where (i.e. should it piggyback on some other file).

Probably just in its own file (we don't do a very good job of keeping a lot of related tests in a single file together - usually just add more files, it's not ideal but often hard to find other good groupings) - but if you're looking for related test files, try breaking the pass in some obvious way

In D94494#2492801, @markus wrote:

bbi-51646.ll1 KBDownload

The issue was found with attached input bbi-51646.ll If necessary it could be added as a regression test but then the question is where (i.e. should it piggyback on some other file).

In D94377#2491956, @MaskRay wrote:

The name SubsequentDelim looks a bit strange to me. Maybe others have suggestions on the name?
(personally I might choose AddDelimUnlessFirst)

In rG6215c1b778f62433f3d79addc299a1bbd0e524d0#969503, @MaskRay wrote:

The called completeUnusedClass is immediately below.

DebugKind <= codegenoptions::DebugLineTablesOnly is a live code path.

In D94439#2491180, @njames93 wrote:

In D94439#2491075, @dblaikie wrote:

I think for full generality the standard library does some things to check if a type can be derived from before using it in this way - but we probably don't need all that machinery for LLVM-internal allocator stuff like this?

We just have to make sure people don't use an allocator that's defined with the final keyword. I doubt we are going to run into many cases of that.
I have done the template magic to get it make it work if someone wants to use an allocator marked final, should I include it?

I think this is here for consistency with the other complete* functions - perhaps it could be left as an assertion?

Might still be a useful conversion for possible future callsites? Or are all the call sites pretty clearly not using this?

Any particular bug you're trying to fix? (this looks like it changes the debug locations, so it would need tests)

Perhaps we could rewrite the code to use ~ or the like instead of unary - if that works?

I think for full generality the standard library does some things to check if a type can be derived from before using it in this way - but we probably don't need all that machinery for LLVM-internal allocator stuff like this?

Looks good - thanks!

Thanks for all the context - so sounds like mostly based on (3) the
recommendation would be for this to be an API test (is there a way to test
the line table directly? good place for reference on the SB API options - I
looked at a few tests and they seemed quite different
( lldb/test/API/functionalities/breakpoint/move_nearest/TestMoveNearest.py
and lldb/test/API/commands/breakpoint/set/func-regex/TestBreakpointRegexError.py
) in the way they're written, so not sure what the norms are/how they work).

Sure, sounds alright.

In D93747#2488390, @tmsriram wrote:

In D93747#2488387, @dblaikie wrote:

Seems alright to me - I think we've hashed out the deeper issues (missing opportunity for C functions which could/should be addressed by moving the implementation to the frontend, where those C functions can be mangled and then use linkageName to give them the same AutoFDO opportunities as C++ functions) here and elsewhere - but for what it is, the patch makes sense. I'd probably say drop the flag - " check if rawLinkageName is set and only set it when it is not null. " was implemented and seems that addressed the debug info issue without an awkward tradeoff between AutoFDO fidelity and debugging fidelity, so there doesn't seem to be a need to be able to configure this.

Here is a suggestion for a plan forward. Let's get these patches along with D94154 in. No correctness issues but a missed opportunity. I will work with @rnk and @dblaikie and send out a patch where I move the uniqueification to clang? That patch will also do linkage name for C functions with mangled name when uniqueification is needed. Does that sound reasonable? As for timeline, I can do this in two weeks.

Seems alright to me - I think we've hashed out the deeper issues (missing opportunity for C functions which could/should be addressed by moving the implementation to the frontend, where those C functions can be mangled and then use linkageName to give them the same AutoFDO opportunities as C++ functions) here and elsewhere - but for what it is, the patch makes sense. I'd probably say drop the flag - " check if rawLinkageName is set and only set it when it is not null. " was implemented and seems that addressed the debug info issue without an awkward tradeoff between AutoFDO fidelity and debugging fidelity, so there doesn't seem to be a need to be able to configure this.

Looks good - thanks!

In D94154#2487745, @hoy wrote:

In D94154#2487727, @dblaikie wrote:

In D94154#2486081, @hoy wrote:

In D94154#2485197, @dblaikie wrote:

In D94154#2482425, @rnk wrote:

In D94154#2481491, @dblaikie wrote:

This is only demangler friendly if the name is already an itanium mangled name, right? (ie: the name starts with _Z) So it wouldn't work for C code?

I'm pretty sure most demangling tools such as c++filt check for a leading prefix of _+Z before demangling, so I don't think there are any concerns for C names. A reasonable demangler would pass them through as is.

Yep - but passing them through unmodified was causing problems for gdb which was demangling the mangled names as they appear in the DWARF and using the unmangled name to figure out how to do name lookup. So if the symbol wasn't getting unmangled you wouldn't be able to "break f1" instead you'd have to "break f1.__part.1" which would be an unfortunate regression in debuggability.

But it seems like that only applies if a mangled name is present in the DWARF at all - if no mangled name is present, and the debug info just gives the pretty name it works OK. Bit weird to have no record of the real symbol name in the DWARF, but so far it doesn't seem to cause any problems? So I'm OK-ish with this.

Do you have plans to fix this more generally? (I think to fix it more generally, you might need to move this feature up to clang and have clang mangle the name then add the suffix (at least for itanium mangling - not sure if windows mangling supports arbitrary suffixes like this, @rnk might know) - that way for C functions you can force/enable the mangling as is done for attribute((overloadable)) and others (I think attribute((enable_if)) also causes mangling of C functions))

That was Sriram's original idea: have the mangler do it. I reviewed the code. Modifying the mangler was fairly complicated, so I suggested doing it in a pass. The original pass also operated by appending a suffix after mangling, it just happened earlier. There isn't a good way to "embed" this uniquification into the Itanium mangling scheme, so far as I am aware.

Oh, I was still in favor of adding it after the mangling (the current "mangled.__part.number") but I thought it may be necessary to force mangling on C functions before adding the suffix, if they needed to be demangleable for debug info purposes.

That all said, I don't see any reason to block this decimilization change. It's limited in scope and an obvious improvement.

My concern was that it was layering more workarounds on a patch series that might be going in the wrong direction overall.

Anyway, sounds like, if I'm understanding/tested correctly, that the issue with unmangleability isn't about the symbol name itself but the DW_AT_linkage_name in the DWARF, so it seems like if that isn't present then there's no issue if the real symbol name can't be unmangled/back to the simple name. (but there's some reason the DW_AT_linkage_name, if present, must match the symbol name? (so it can't be the original unsuffixed mangled name))

One reason that DW_AT_linkage_name should be consistent with the real linkage name is to favor AutoFDO. DW_AT_linkage_name is used to generate profiles for inlined functions.

How's this work for C functions? Same sort of problem?

Yes, same problem exists for C functions. For C functions without DW_AT_linkage_name, DW_AT_name will be used by AutoFDO and that's not uniquefied.

In D94154#2486081, @hoy wrote:

In D94154#2485197, @dblaikie wrote:

In D94154#2482425, @rnk wrote:

In D94154#2481491, @dblaikie wrote:

This is only demangler friendly if the name is already an itanium mangled name, right? (ie: the name starts with _Z) So it wouldn't work for C code?

I'm pretty sure most demangling tools such as c++filt check for a leading prefix of _+Z before demangling, so I don't think there are any concerns for C names. A reasonable demangler would pass them through as is.

Yep - but passing them through unmodified was causing problems for gdb which was demangling the mangled names as they appear in the DWARF and using the unmangled name to figure out how to do name lookup. So if the symbol wasn't getting unmangled you wouldn't be able to "break f1" instead you'd have to "break f1.__part.1" which would be an unfortunate regression in debuggability.

But it seems like that only applies if a mangled name is present in the DWARF at all - if no mangled name is present, and the debug info just gives the pretty name it works OK. Bit weird to have no record of the real symbol name in the DWARF, but so far it doesn't seem to cause any problems? So I'm OK-ish with this.

Do you have plans to fix this more generally? (I think to fix it more generally, you might need to move this feature up to clang and have clang mangle the name then add the suffix (at least for itanium mangling - not sure if windows mangling supports arbitrary suffixes like this, @rnk might know) - that way for C functions you can force/enable the mangling as is done for attribute((overloadable)) and others (I think attribute((enable_if)) also causes mangling of C functions))

That was Sriram's original idea: have the mangler do it. I reviewed the code. Modifying the mangler was fairly complicated, so I suggested doing it in a pass. The original pass also operated by appending a suffix after mangling, it just happened earlier. There isn't a good way to "embed" this uniquification into the Itanium mangling scheme, so far as I am aware.

Oh, I was still in favor of adding it after the mangling (the current "mangled.__part.number") but I thought it may be necessary to force mangling on C functions before adding the suffix, if they needed to be demangleable for debug info purposes.

That all said, I don't see any reason to block this decimilization change. It's limited in scope and an obvious improvement.

My concern was that it was layering more workarounds on a patch series that might be going in the wrong direction overall.

Anyway, sounds like, if I'm understanding/tested correctly, that the issue with unmangleability isn't about the symbol name itself but the DW_AT_linkage_name in the DWARF, so it seems like if that isn't present then there's no issue if the real symbol name can't be unmangled/back to the simple name. (but there's some reason the DW_AT_linkage_name, if present, must match the symbol name? (so it can't be the original unsuffixed mangled name))

One reason that DW_AT_linkage_name should be consistent with the real linkage name is to favor AutoFDO. DW_AT_linkage_name is used to generate profiles for inlined functions.

Looks good

In D94063#2485271, @labath wrote:

In D94063#2483546, @dblaikie wrote:

If it's better to write it using C++ source and custom clang flags I can do that instead (it'll be an -mllvm flag - looks like there's one other test that does that: lldb/test/API/lang/objc/forward-decl/TestForwardDecl.py: dict(CFLAGS_EXTRAS="-dwarf-version=5 -mllvm -accel-tables=Dwarf"))) - means the test will be a bit more convoluted to tickle the subprogram ranges, but not much - just takes two functions+function-sections.

I certainly wouldn't want to drop the existing test.

In D94154#2482425, @rnk wrote:

In D94154#2481491, @dblaikie wrote:

This is only demangler friendly if the name is already an itanium mangled name, right? (ie: the name starts with _Z) So it wouldn't work for C code?

I'm pretty sure most demangling tools such as c++filt check for a leading prefix of _+Z before demangling, so I don't think there are any concerns for C names. A reasonable demangler would pass them through as is.

In D93876#2484997, @tmsriram wrote:

In D93876#2484989, @dblaikie wrote:

I guess if they use bb-sections but not function-sections that assumes selective bb-sections would apply to all the hot functions? So that lets the hot code be reordered, and all the functions that aren't bb-split would go in one big .text section and be considered "not hot"?

Yep, +1 on the last point. That is what I was trying to say but clearly failed to communicate as well :)

In D93876#2483702, @tmsriram wrote:

In D93876#2474377, @dblaikie wrote:

This patch disables this implicit behavior. It only creates function sections for those functions that require basic block sections.

Is this necessary? I would guess even with a bb sections function, its main section could go in the generic .text section?

But we want the .text section to be unique because we want reorder functions at link time. Does that make sense?

In D93030#2484272, @CarolineConcatto wrote:

I push the fix patch to main in the commit:
01c190e907ca

Looks good, thanks!

In D94064#2481925, @labath wrote:

I don't think that simply setting func_lo_pc to zero will be sufficient to make this work. I would expect this to break in more complicated scenarios (like, even if we just have two of these functions). I think the only reason it works in this case is because for this particular function, it's base address (relative to the CU base) *is* zero.

Use image lookup to make test runnable without executing the test code

In D94063#2481867, @labath wrote:

The fix is good, but the test could be improved.

Update test to avoid running the program