LGTM, thanks!

The fix resolves the issue on my environment. Thank you for the quick response!

This change causes build failures in my Windows environment.

Looks good, thanks!

LGTM, thanks!

In D96409#2575680, @dblaikie wrote:

In D96409#2574186, @ikudrin wrote:

More in the sense that it limits the flexibility of calling code without any real profit. For example, the caller now cannot create the label in advance.

Any particular benefit to being able to do that, though? I think this is similar to rolling "Lo" into the function - the caller now can't reuse that label, but it doesn't seem especially important/beneficial to be able to reuse it, compared to simplifying the API.

Why should a service class like MCStreamer define the architecture of its clients? It is just not its area of responsibility.

In D96865#2575486, @gregmiller wrote:

Do you have any suggestions on why we would start seeing above failures after you commit? Was passing before.

In D96409#2572715, @dblaikie wrote:

At some point it'd probably be good to include a second (probably as the first parameter) to this function to use as a prefix for the label names to make them more informative/easier to read/modify/etc.

Maybe it'll make sense to do that in this patch. There will be fewer changes in the tests.

(Moving the thread, as it's more suitable here)

In D95998#2572951, @dblaikie wrote:

In D95998#2568193, @ikudrin wrote:

In D95998#2567599, @dblaikie wrote:

What if the function created and returned Hi rather than taking it as an argument?

Hmm, I can't say I'm a vivid fan of this change. All methods of MCStremer instruct it to do something, i.e. it roles as just a performer. With this change, it now requests a caller to do some action. It looks like inverting customer vs. performer roles for this particular case.

In the sense that it now requests the user emit the end label at some point?

More in the sense that it limits the flexibility of calling code without any real profit. For example, the caller now cannot create the label in advance. For instance, Dwarf5AccelTableWriter::ContributionEnd was initialized when the object of that class was created. Simple and solid. Now the initialization is postponed until a method of another class, Dwarf5AccelTableWriter::Header is called. The tracking is a bit more challenging now.

Thanks!

In D95998#2567599, @dblaikie wrote:

What if the function created and returned Hi rather than taking it as an argument?

In D96710#2567786, @shchenz wrote:

@ikudrin Hi, we made another change for emitDwarfUnitLength in D96409, I think this patch needs to be further improved for Hi parameter. Let me know if you need me to update this patch. Thanks.

In D96710#2566459, @dblaikie wrote:

Sure, sounds OK. Though a lot of this is probably OK/already tested by assembly level tests, I'd expect.

Ping. What should be done to proceed with this?

@shchenz, please take a look at D96710. When it is accepted, you can integrate it here or commit it separately within the whole set.

I guess we can simplify that even further by emitting the temporary symbol right after the "length of the prologue" field. In that case, PreHeaderLengthBytes will not be needed at all.

Thank you, @dblaikie!

In D94668#2553464, @shchenz wrote:

Do you have any idea about how to do this? @ikudrin My requirement here is: I need to add the endSymbol for asm streamer at the end of .text section to indicate the end of the text section.
Object streamer can easily do this by calling MCSymbol *endSection(Section) in emitDwarfLineTable, but this does not work for asm streamer. When we are generating assembly output for .debug_line section, we can not go back to .text section and emit an end symbol there. I think this is not supported.

In D95998#2553440, @shchenz wrote:

In D95998#2553412, @ikudrin wrote:

The idea was to remove the Lo argument from MCStreamer::emitDwarfUnitLength(Hi, Lo, Comment) so that it becomes just MCStreamer::emitDwarfUnitLength(Hi, Comment). A temporary symbol can be created and emitted inside the method. And that should be a separate NFC patch.

We need to differentiate the temp symbol names for different debug sections like debug info, debug pubnames, debug line to make a more readable assembly output. That's the first reason I put the temp symbol created outside.

The idea was to remove the Lo argument from MCStreamer::emitDwarfUnitLength(Hi, Lo, Comment) so that it becomes just MCStreamer::emitDwarfUnitLength(Hi, Comment). A temporary symbol can be created and emitted inside the method. And that should be a separate NFC patch.

In D94668#2553258, @shchenz wrote:

Gentle ping...

We still need this patch for D95518 for lib/Target/PowerPC/PPCAsmPrinter.cpp file. We need to emit the end symbol for asmstreamer to tell where is the end of the text section.

There is no need to create a new MCStreamer::emitDwarfLineUnitLength() method and make all the dependencies public. It is better to just use the already existed MCStreamer::emitDwarfUnitLength(). All you need to do is to create a temporary symbol and emit it right after calling emitDwarfUnitLength().

In D96144#2548663, @probinson wrote:

I've re-read a fair amount of the previous llvm-dev thread.
One goal of doing a patch like this was to collect some performance data; do we have that? In particular, performance data comparing link times with the option default-on versus default-off, so we can determine whether the difference is small enough that we should just do this processing unconditionally.

There were so many ideas in the discussion that it looked like they not going to converge. The idea of waiting for v6 does not resolve the issue for existing standards, just postpones the possible solution for years with a yet unknown result. Adding new section names, flags, types, etc., might be promising at the first glance but requires updating lots of tools, including tools in different toolchains, which complicates achieving the result even further. That is why I feel it is necessary to illustrate my proposal with a complete patch, which is aimed to show that a simple, efficient, and standard-compliant solution is possible.

LGTM but please postpone committing it until the whole set of patches is completed so we can have a full image of the changes.

Seems OK. Something similar is in exception_object_alignment.pass.cpp.

In D95200#2538388, @MaskRay wrote:

I am not sure libunwind's ARMEH implementation has working _Unwind_ForcedUnwind so looks like the best is to unsupport arm. How to do that?

It looks like my idea was not well-thought.

In D94670#2532465, @hubert.reinterpretcast wrote:

In D94670#2531880, @ikudrin wrote:

Is it possible to use a .set pseudo-op to define a symbol that can be referenced from other sections?

See https://reviews.llvm.org/D94670#2501150. It seems to work. Do you have a suggestion on how to make use of it from the MC layer here?

The comment was originally sent to D94668, but it looks like it suits here better.

Is it possible to encapsulate the target-specific logic into some derived classes from MCStreamer so that MCStreamer itself and DWARF emitter classes work through a common interface and have no target-specific adjustments?

I suppose that you describe how .dwsect pseudo-op works. That is quite interesting, why they designed the feature to work that way. Is it recommended to reference debug sections through the label minus the length field size (4 or 12) or they provide some means to simplify the calculation? How an assembler output of their own compiler looks like?

Trying to force CI to run.

• Updated as suggested. Thanks, @ldionne!

The current code violates the C++ standard, which says (in different sections, depending on the version):

It looks like lld/test/COFF/lto-new-pass-manager.ll.obj was added to the patch by accident and should be removed.

Well, this is a bit different from my original idea but is an overall good heuristic for many of the debug sections. It works for .debug_info, which is one of the biggest sections; it does not work for .debug_line, though, which is not that big as .debug_info, but potentially might become problematic in the (distant) future; it also does not work for .debug_abbrev, .debug_addr, .debug_ranges, and some others, which are usually not that big. However, the patch should be extended to support .debug_str, which can be even larger than .debug_info.

In D87011#2378347, @jhenderson wrote:

At least in LLD, it's not quite as simple as being added after the user's code: if a library appears on the link line it will be included in the output order as soon as it is determined it is needed. Thus if you have have three modules 1.o, 2.o, and 3.o, with 3.o in an archive 3.a and 1.o requiring 3.o, you end up with an output order of 1.o 3.o 2.o if the input order was 1.o 3.a 2.o or 3.a 1.o 2.o or an output order of 1.o 2.o 3.o if the input order was 1.o 2.o 3.a. In fact, with use of the --undefined linker switch, you can even force 3.o to appear first.

I accept using --undefined or rearranging the command-line order is less than ideal, but I'm really not convinced LLD should have any place in parsing the DWARF to determine output order. Furthermore, it's not even a reliable solution - if the objects built with DWARF32 (potentially all of which might have come from libraries) are large enough, no amount of reordering will fix the behaviour. I think users who need DWARF64 in their libraries are just going to have to request DWARF64 versions of the libraries, if the --undefined and reordering command line options are insufficient.

In D87011#2378224, @jhenderson wrote:

I wouldn't expect LLD to need to do anything specific for DWARF64 support. It should generally speaking be treating the sections as opaque, in my opinion, and treat them no differently to other sections. If a user is mixing DWARF32 and DWARF64, then I'd say it's on their heads if relocations can't reach (just the same as it is if they're using DWARF32 but really need DWARF64). Any interactions LLD does have with the contents of the DWARF sections should be controlled via the DebugInfo library, and therefore if that library works for DWARF64, LLD doesn't need any special handling.

1. The patch needs tests to check the added functionality.
2. DWARF64 can be generated only for a limited number of targets. There should be diagnostics for invalid switch combinations to prevent misuse. @MaskRay mentioned that in the patch for llc, D87011#2254749, but that makes a lot more sense for user-level tools.

I suppose that it would be helpful to arrange debugging information sections so that DWARF64 comes after DWARF32, otherwise, some 32-bit relocations in the 32-bit info could not be resolved. But that idea might be a bit controversial because usually debugging information is expected to have the same order as the sections it refers to.

To generate 64-bit debugging info, there should be enough to pass the switch through CLANG, right. Apart from that, we will probably need some compatibility checks so that using the switch in unsupported cases prints out diagnostics. There are also some improvements on the LLD side which are better to be done to support extremely large debugging information. Not all our tools fully support DWARF64 yet, etc.

The switch is implemented only internally in LLVM. There is still some work to be done to enable producing 64-bit debugging info in clang, but I strayed a bit for another task. Hope to come back later this year.

In D87011#2357977, @ayermolo wrote:

@ikudrin To clarify this will emit R_X86_64_64 bit relocations for .debug_info on 64 bit platform, correct?

In D88877#2350507, @MaskRay wrote:

I am still concerned that we go down this route (workaround in the linker rather than teach the user to add --no-whole-archive just because of convenience adding logic in the linker). Among --push-state pushed states, --as-needed and -Bstatic may be states users want to keep for the dependent libraries.

• Updated the test as suggested. Thanks, @bd1976llvm!

In D88877#2342920, @bd1976llvm wrote:

I think I agree that build systems might not easily be able to arrange for appending options to the end of the linker command line. Therefore, for the "dependent libraries" feature (I changed the name in https://reviews.llvm.org/D60274 because autolinking was too general) it would be reasonable to reset any temporal options that the build system would otherwise have to handle by appending an argument to the very end of the command line (e.g. --whole-archives). Where appropriate we can create new order-independent options to apply the options that are reset to the dependent libraries. This seems like an improvement over what we have now.

Hmm, that starts looking like a discussion for the mailing list, but I guess that all interested people are already here and the conversation will be better preserved for further references if being linked to the review.

In D88877#2331416, @bd1976llvm wrote:

Firstly, is this a real problem?

Gently ping. Is there anything I can improve in the fix so that it is accepted?

I've made some tests and speculatively estimate the saving up to several seconds for a relatively large library (about 100000 symbols) which is referenced several hundred times. For me, that is noticeable.

In D88944#2316011, @MaskRay wrote:

I am skeptical about the change.

• The duplicated libraries are usually indicator of user errors or build system brittleness.

• Simplified the comment.

• Fixed the comment.

D87008 added creating a test AsmPrinter to the CodeGen unit tests, so it is now possible to fix the DIEHashTest.MemberBlock so that it provides an instance to the tested class.