Introduce and use a new section type for the bb_addr_map section.

[rahmanl]

Summary

This patch lets the bb_addr_map (renamed to __llvm_bb_addr_map) section use a special section type (SHT_LLVM_BB_ADDR_MAP) instead of SHT_PROGBITS. This would help parsers, dumpers and other tools to use the sh_type ELF field to identify this section rather than relying on string comparison on the section name.

[jhenderson]

Mostly looks okay. I think there is no testing for the assembly parser being able to parse the new section type?

I'm also keen to hear what others think (e.g. @MaskRay).

llvm/lib/CodeGen/AsmPrinter/AsmPrinter.cpp

1025–1026

Please make sure to run clang-format on all the bits of code you've modified.

[rahmanl]

• Add new test for MCParser.
• Clang-format.

[rahmanl]

Thanks @jhenderson, turned out I did need a one-line change for asmparser to work.

[MaskRay]

In D88199#2292193, @jhenderson wrote:

Mostly looks okay. I think there is no testing for the assembly parser being able to parse the new section type?

I'm also keen to hear what others think (e.g. @MaskRay).

This patch lets the bb_addr_map (renamed to llvm_bb_addr_map) section use a special section type (SHT_LLVM_BB_ADDR_MAP) instead of SHT_PROGBITS. This would help linker and other tools to use the sh_type ELF field to identify this section rather than relying on string comparison on the section name.

This description implies that some special processing is needed in the linker. (As you can see, when llvm_call_graph_profile and llvm_dependent_libraries were proposed, they had clear patches on the linker side.)

llvm/test/MC/AsmParser/section_types.s

13

@note is covered by other tests.

Keeping just llvm specific section types here should be fine.

[jhenderson]

In D88199#2295596, @MaskRay wrote:

In D88199#2292193, @jhenderson wrote:

Mostly looks okay. I think there is no testing for the assembly parser being able to parse the new section type?

I'm also keen to hear what others think (e.g. @MaskRay).

This patch lets the bb_addr_map (renamed to llvm_bb_addr_map) section use a special section type (SHT_LLVM_BB_ADDR_MAP) instead of SHT_PROGBITS. This would help linker and other tools to use the sh_type ELF field to identify this section rather than relying on string comparison on the section name.

This description implies that some special processing is needed in the linker. (As you can see, when llvm_call_graph_profile and llvm_dependent_libraries were proposed, they had clear patches on the linker side.)

Maybe pivot the statement to say "dumpers and other tools"? Dumpers will need to know the section type for simpler processing of the code, even if the linker has no special handling currently.

[rahmanl]

• Remove non-llvm section types from the test.
• Rebase.

[rahmanl]

• Rename test to llvm_section_types.

[rahmanl]

Thanks @MaskRay and @jhenderson.
Changed the description and the test according to your comments.

[MaskRay]

In D88199#2297495, @jhenderson wrote:

In D88199#2295596, @MaskRay wrote:

In D88199#2292193, @jhenderson wrote:

Mostly looks okay. I think there is no testing for the assembly parser being able to parse the new section type?

I'm also keen to hear what others think (e.g. @MaskRay).

This patch lets the bb_addr_map (renamed to llvm_bb_addr_map) section use a special section type (SHT_LLVM_BB_ADDR_MAP) instead of SHT_PROGBITS. This would help linker and other tools to use the sh_type ELF field to identify this section rather than relying on string comparison on the section name.

This description implies that some special processing is needed in the linker. (As you can see, when llvm_call_graph_profile and llvm_dependent_libraries were proposed, they had clear patches on the linker side.)

Maybe pivot the statement to say "dumpers and other tools"? Dumpers will need to know the section type for simpler processing of the code, even if the linker has no special handling currently.

xray_instr_map and xray_fn_idx are also an LLVM specific section types but they do not get their own section types. They use a dedicated dumper (llvm-xray), instead of llvm-readobj.

If the eventual behavior is to let LLD interpret .bb_addr_map differently (like .deplibs and .llvm_sympart*) differently (not "Rules for Linking Unrecognized Sections" on http://www.sco.com/developers/gabi/latest/ch4.sheader.html), having a dedicated section type seems fine. Though, I'd really like to know whether auto-defined __start_bb_addr_map and __stop_bb_addr_map are needed. If yes, the section name should not start with a period. And I'd like to know how the section is differently interpreted. xray_instr_map and xray_fn_idx only use generic ELF features.

[rahmanl]

In D88199#2298841, @MaskRay wrote:

In D88199#2297495, @jhenderson wrote:

In D88199#2295596, @MaskRay wrote:

In D88199#2292193, @jhenderson wrote:

Mostly looks okay. I think there is no testing for the assembly parser being able to parse the new section type?

I'm also keen to hear what others think (e.g. @MaskRay).

This patch lets the bb_addr_map (renamed to llvm_bb_addr_map) section use a special section type (SHT_LLVM_BB_ADDR_MAP) instead of SHT_PROGBITS. This would help linker and other tools to use the sh_type ELF field to identify this section rather than relying on string comparison on the section name.

This description implies that some special processing is needed in the linker. (As you can see, when llvm_call_graph_profile and llvm_dependent_libraries were proposed, they had clear patches on the linker side.)

Maybe pivot the statement to say "dumpers and other tools"? Dumpers will need to know the section type for simpler processing of the code, even if the linker has no special handling currently.

xray_instr_map and xray_fn_idx are also an LLVM specific section types but they do not get their own section types. They use a dedicated dumper (llvm-xray), instead of llvm-readobj.

If the eventual behavior is to let LLD interpret .bb_addr_map differently (like .deplibs and .llvm_sympart*) differently (not "Rules for Linking Unrecognized Sections" on http://www.sco.com/developers/gabi/latest/ch4.sheader.html), having a dedicated section type seems fine. Though, I'd really like to know whether auto-defined __start_bb_addr_map and __stop_bb_addr_map are needed. If yes, the section name should not start with a period. And I'd like to know how the section is differently interpreted. xray_instr_map and xray_fn_idx only use generic ELF features.

No, there are no plans to treat this section differently in LLD. However, we will have an external tool parsing this section. Also we don't need start and stop symbols.

[jhenderson]

I noticed that there are other LLVM sections which use __llvm_* as a prefix for their section name, instead of .llvm_* or .llvm.* (see e.g. __llvm_prf_cnts). What do you think about using that style for the name? It's not necessary, and it looks like we have a bit of inconsistency going on here, but it's something worth considering.

[rahmanl]

In D88199#2302543, @jhenderson wrote:

I noticed that there are other LLVM sections which use __llvm_* as a prefix for their section name, instead of .llvm_* or .llvm.* (see e.g. __llvm_prf_cnts). What do you think about using that style for the name? It's not necessary, and it looks like we have a bit of inconsistency going on here, but it's something worth considering.

That's possible too, but just to verify, do we still want to add the new section type?

[jhenderson]

Personally, I think we should still have a new section type - the section has a well-defined structure, which in turn means it can be parsed and dumped. We shouldn't need to use section names to distinguish it from other sections to determine which section to parse or dump.

[rahmanl]

• Rename section to __llvm_bb_addr_map.

[rahmanl]

Diff reupload.

[rahmanl]

@MaskRay Do you think this is fine now?

[MaskRay]

In D88199#2302543, @jhenderson wrote:

I noticed that there are other LLVM sections which use __llvm_* as a prefix for their section name, instead of .llvm_* or .llvm.* (see e.g. __llvm_prf_cnts). What do you think about using that style for the name? It's not necessary, and it looks like we have a bit of inconsistency going on here, but it's something worth considering.

I am not sure it will be a good idea. The start/stop symbols of __llvm_prf_cnts is __start___llvm_prf_cnts and __stop___llvm_prf_cnts. The 3 _ look strange.

If the optimization eventually will be ported to Mach-O: strlen("__llvm_prf_cnts") <= 16 so the section name can be encoded in Mach-O. __llvm_bb_addr_map is not.

[rahmanl]

Revert back to using ".llvm_bb_addr_map" for the section name.

[rahmanl]

In D88199#2312785, @MaskRay wrote:

In D88199#2302543, @jhenderson wrote:

I noticed that there are other LLVM sections which use __llvm_* as a prefix for their section name, instead of .llvm_* or .llvm.* (see e.g. __llvm_prf_cnts). What do you think about using that style for the name? It's not necessary, and it looks like we have a bit of inconsistency going on here, but it's something worth considering.

I am not sure it will be a good idea. The start/stop symbols of __llvm_prf_cnts is __start___llvm_prf_cnts and __stop___llvm_prf_cnts. The 3 _ look strange.

Right. We won't be using the __start and __stop symbols.

If the optimization eventually will be ported to Mach-O: strlen("__llvm_prf_cnts") <= 16 so the section name can be encoded in Mach-O. __llvm_bb_addr_map is not.

Good point. Actually this shows the importance of using the section type as opposed to the section name. If necessary, we can always change the section name since we make sure we never rely on the actual name.

[jhenderson]

LGTM, but please wait for @MaskRay to give any final thoughts.

Also subscribing @grimar who is involved heavily in the ELF binutils/LLD too, in case he's got any comments.

[grimar]

I think you also need to update the documentation: llvm\docs\Extensions.rst (https://llvm.org/docs/Extensions.html)

llvm/test/MC/AsmParser/llvm_section_types.s

2 ↗

(On Diff #296366)

Perhaps just i386-pc-linux, as there is nothing GNU specific here.

3 ↗

(On Diff #296366)

15 ↗

(On Diff #296366)

Add an empty line to separate the code and checks?

[rahmanl]

• Add entry in docs/Extensions.rst.
• Address @grimar's comments.

[rahmanl]

Thanks @grimar.
I added the entry in the Extensions doc. I am not sure if my formatting is correct. I appreciate if you could please take a look.

[rahmanl]

• Format Extensions.rst.

[grimar]

In D88199#2318352, @rahmanl wrote:

Thanks @grimar.
I added the entry in the Extensions doc. I am not sure if my formatting is correct. I appreciate if you could please take a look.

I am not an expert in this area too, but it looks consistent with the rest of the file, so I think it is fine.
To recheck myself I've used "Online Sphinx editor" (https://livesphinx.herokuapp.com/) and its output looks fine to me too.
I've inlined a comment about a single concern/nit I have though.

llvm/docs/Extensions.rst

411 ↗

(On Diff #296838)

Does #### has some special meaning? If not, I'd just put '#', that is the way other comments
are marked in the file.

[rahmanl]

• Remove extra '#'s from Extensions.rst.

[rahmanl]

Thanks everyone for the review. I'll go ahead and commit this and start working on D88717.

llvm/include/llvm/BinaryFormat/ELF.h

enum : unsigned {
   SHT_ANDROID_REL = 0x60000001,
   SHT_ANDROID_RELA = 0x60000002,
   SHT_LLVM_ODRTAB = 0x6fff4c00,             // LLVM ODR table.
   SHT_LLVM_LINKER_OPTIONS = 0x6fff4c01,     // LLVM Linker Options.
   SHT_LLVM_CALL_GRAPH_PROFILE = 0x6fff4c02, // LLVM Call Graph Profile.
   SHT_LLVM_ADDRSIG = 0x6fff4c03, // List of address-significant symbols
                                  // for safe ICF.
   SHT_LLVM_DEPENDENT_LIBRARIES =
-      0x6fff4c04,                  // LLVM Dependent Library Specifiers.
-  SHT_LLVM_SYMPART = 0x6fff4c05,   // Symbol partition specification.
-  SHT_LLVM_PART_EHDR = 0x6fff4c06, // ELF header for loadable partition.
-  SHT_LLVM_PART_PHDR = 0x6fff4c07, // Phdrs for loadable partition.
+      0x6fff4c04,                    // LLVM Dependent Library Specifiers.
+  SHT_LLVM_SYMPART = 0x6fff4c05,     // Symbol partition specification.
+  SHT_LLVM_PART_EHDR = 0x6fff4c06,   // ELF header for loadable partition.
+  SHT_LLVM_PART_PHDR = 0x6fff4c07,   // Phdrs for loadable partition.
+  SHT_LLVM_BB_ADDR_MAP = 0x6fff4c08, // LLVM Basic Block Address Map.
   // Android's experimental support for SHT_RELR sections.
   // https://android.googlesource.com/platform/bionic/+/b7feec74547f84559a1467aca02708ff61346d2a/libc/include/elf.h#512
   SHT_ANDROID_RELR = 0x6fffff00,   // Relocation entries; only offsets.
   SHT_GNU_ATTRIBUTES = 0x6ffffff5, // Object attributes.
   SHT_GNU_HASH = 0x6ffffff6,       // GNU-style hash table.
   SHT_GNU_verdef = 0x6ffffffd,     // GNU version definitions.
   SHT_GNU_verneed = 0x6ffffffe,    // GNU version references.
   SHT_GNU_versym = 0x6fffffff,     // GNU symbol versions table.

llvm/lib/CodeGen/AsmPrinter/AsmPrinter.cpp

void AsmPrinter::emitFrameAlloc(const MachineInstr &MI) {
   // The operands are the MCSymbol and the frame offset of the allocation.
   MCSymbol *FrameAllocSym = MI.getOperand(0).getMCSymbol();
   int FrameOffset = MI.getOperand(1).getImm();
 
   // Emit a symbol assignment.
   OutStreamer->emitAssignment(FrameAllocSym,
                              MCConstantExpr::create(FrameOffset, OutContext));
 }
 
-/// Returns the BB metadata to be emitted in the bb_addr_map section for a given
-/// basic block. This can be used to capture more precise profile information.
-/// We use the last 3 bits (LSBs) to ecnode the following information:
+/// Returns the BB metadata to be emitted in the .llvm_bb_addr_map section for a
+/// given basic block. This can be used to capture more precise profile
+/// information. We use the last 3 bits (LSBs) to ecnode the following
+/// information:
 ///  * (1): set if return block (ret or tail call).
 ///  * (2): set if ends with a tail call.
 ///  * (3): set if exception handling (EH) landing pad.
 /// The remaining bits are zero.
 static unsigned getBBAddrMapMetadata(const MachineBasicBlock &MBB) {
   const TargetInstrInfo *TII = MBB.getParent()->getSubtarget().getInstrInfo();
   return ((unsigned)MBB.isReturnBlock()) |
          ((!MBB.empty() && TII->isTailCall(MBB.back())) << 1) |
          (MBB.isEHPad() << 2);
 }
 
 void AsmPrinter::emitBBAddrMapSection(const MachineFunction &MF) {
   MCSection *BBAddrMapSection =
       getObjFileLowering().getBBAddrMapSection(*MF.getSection());
-  assert(BBAddrMapSection && ".bb_addr_map section is not initialized.");
+  assert(BBAddrMapSection && ".llvm_bb_addr_map section is not initialized.");
 
   const MCSymbol *FunctionSymbol = getFunctionBegin();
 
   OutStreamer->PushSection();
   OutStreamer->SwitchSection(BBAddrMapSection);
   OutStreamer->emitSymbolValue(FunctionSymbol, getPointerSize());
   // Emit the total number of basic blocks in this function.
   OutStreamer->emitULEB128IntValue(MF.size());

llvm/lib/CodeGen/BasicBlockSections.cpp

 //    emitted with more relocations as basic block sections can break a
 //    function into potentially several disjoint pieces, and CFI needs to be
 //    emitted per cluster. This also bloats the object file and binary sizes.
 //
 // Basic Block Labels
 // ==================
 //
 // With -fbasic-block-sections=labels, we emit the offsets of BB addresses of
-// every function into a .bb_addr_map section. Along with the function symbols,
-// this allows for mapping of virtual addresses in PMU profiles back to the
-// corresponding basic blocks. This logic is implemented in AsmPrinter. This
+// every function into the .llvm_bb_addr_map section. Along with the function
+// symbols, this allows for mapping of virtual addresses in PMU profiles back to
+// the corresponding basic blocks. This logic is implemented in AsmPrinter. This
 // pass only assigns the BBSectionType of every function to ``labels``.
 //
 //===----------------------------------------------------------------------===//
 
 #include "llvm/ADT/Optional.h"
 #include "llvm/ADT/SmallSet.h"
 #include "llvm/ADT/SmallVector.h"
 #include "llvm/ADT/StringMap.h"

llvm/lib/MC/MCObjectFileInfo.cpp

MCObjectFileInfo::getBBAddrMapSection(const MCSection &TextSec) const {
   const MCSectionELF &ElfSec = static_cast<const MCSectionELF &>(TextSec);
   unsigned Flags = ELF::SHF_LINK_ORDER;
   StringRef GroupName;
   if (const MCSymbol *Group = ElfSec.getGroup()) {
     GroupName = Group->getName();
     Flags |= ELF::SHF_GROUP;
   }
 
-  return Ctx->getELFSection(".bb_addr_map", ELF::SHT_PROGBITS, Flags, 0,
-                            GroupName, MCSection::NonUniqueID,
+  return Ctx->getELFSection(".llvm_bb_addr_map", ELF::SHT_LLVM_BB_ADDR_MAP,
+                            Flags, 0, GroupName, MCSection::NonUniqueID,
                             cast<MCSymbolELF>(TextSec.getBeginSymbol()));
 }

llvm/lib/MC/MCParser/ELFAsmParser.cpp

if (TypeName.empty()) {
     else if (TypeName == "llvm_linker_options")
       Type = ELF::SHT_LLVM_LINKER_OPTIONS;
     else if (TypeName == "llvm_call_graph_profile")
       Type = ELF::SHT_LLVM_CALL_GRAPH_PROFILE;
     else if (TypeName == "llvm_dependent_libraries")
       Type = ELF::SHT_LLVM_DEPENDENT_LIBRARIES;
     else if (TypeName == "llvm_sympart")
       Type = ELF::SHT_LLVM_SYMPART;
+    else if (TypeName == "llvm_bb_addr_map")
+      Type = ELF::SHT_LLVM_BB_ADDR_MAP;
     else if (TypeName.getAsInteger(0, Type))
       return TokError("unknown section type");
   }
 
   if (UseLastGroup) {
     MCSectionSubPair CurrentSection = getStreamer().getCurrentSection();
     if (const MCSectionELF *Section =
             cast_or_null<MCSectionELF>(CurrentSection.first))

llvm/lib/MC/MCSectionELF.cpp

void MCSectionELF::PrintSwitchToSection(const MCAsmInfo &MAI, const Triple &T,
   else if (Type == ELF::SHT_LLVM_LINKER_OPTIONS)
     OS << "llvm_linker_options";
   else if (Type == ELF::SHT_LLVM_CALL_GRAPH_PROFILE)
     OS << "llvm_call_graph_profile";
   else if (Type == ELF::SHT_LLVM_DEPENDENT_LIBRARIES)
     OS << "llvm_dependent_libraries";
   else if (Type == ELF::SHT_LLVM_SYMPART)
     OS << "llvm_sympart";
+  else if (Type == ELF::SHT_LLVM_BB_ADDR_MAP)
+    OS << "llvm_bb_addr_map";
   else
     report_fatal_error("unsupported type 0x" + Twine::utohexstr(Type) +
                        " for section " + getName());
 
   if (EntrySize) {
     assert(Flags & ELF::SHF_MERGE);
     OS << "," << EntrySize;
   }

llvm/lib/Object/ELF.cpp

switch (Type) {
     STRINGIFY_ENUM_CASE(ELF, SHT_LLVM_ODRTAB);
     STRINGIFY_ENUM_CASE(ELF, SHT_LLVM_LINKER_OPTIONS);
     STRINGIFY_ENUM_CASE(ELF, SHT_LLVM_CALL_GRAPH_PROFILE);
     STRINGIFY_ENUM_CASE(ELF, SHT_LLVM_ADDRSIG);
     STRINGIFY_ENUM_CASE(ELF, SHT_LLVM_DEPENDENT_LIBRARIES);
     STRINGIFY_ENUM_CASE(ELF, SHT_LLVM_SYMPART);
     STRINGIFY_ENUM_CASE(ELF, SHT_LLVM_PART_EHDR);
     STRINGIFY_ENUM_CASE(ELF, SHT_LLVM_PART_PHDR);
+    STRINGIFY_ENUM_CASE(ELF, SHT_LLVM_BB_ADDR_MAP);
     STRINGIFY_ENUM_CASE(ELF, SHT_GNU_ATTRIBUTES);
     STRINGIFY_ENUM_CASE(ELF, SHT_GNU_HASH);
     STRINGIFY_ENUM_CASE(ELF, SHT_GNU_verdef);
     STRINGIFY_ENUM_CASE(ELF, SHT_GNU_verneed);
     STRINGIFY_ENUM_CASE(ELF, SHT_GNU_versym);
   default:
     return "Unknown";
   }

llvm/test/CodeGen/X86/basic-block-sections-labels-functions-sections.ll

 ; RUN: llc < %s -mtriple=x86_64 -function-sections -basic-block-sections=labels | FileCheck %s
 
 $_Z4fooTIiET_v = comdat any
 
 define dso_local i32 @_Z3barv() {
   ret i32 0
 }
-;; Check we add SHF_LINK_ORDER for .bb_addr_map and link it with the corresponding .text sections.
+;; Check we add SHF_LINK_ORDER for .llvm_bb_addr_map and link it with the corresponding .text sections.
 ; CHECK:    .section .text._Z3barv,"ax",@progbits
 ; CHECK-LABEL:  _Z3barv:
 ; CHECK-NEXT: [[BAR_BEGIN:.Lfunc_begin[0-9]+]]:
-; CHECK:    .section .bb_addr_map,"o",@progbits,.text._Z3barv{{$}}
+; CHECK:    .section .llvm_bb_addr_map,"o",@llvm_bb_addr_map,.text._Z3barv{{$}}
 ; CHECK-NEXT:   .quad [[BAR_BEGIN]]
 
 
 define dso_local i32 @_Z3foov() {
   %1 = call i32 @_Z4fooTIiET_v()
   ret i32 %1
 }
 ; CHECK:    .section .text._Z3foov,"ax",@progbits
 ; CHECK-LABEL:  _Z3foov:
 ; CHECK-NEXT: [[FOO_BEGIN:.Lfunc_begin[0-9]+]]:
-; CHECK:    .section  .bb_addr_map,"o",@progbits,.text._Z3foov{{$}}
+; CHECK:    .section  .llvm_bb_addr_map,"o",@llvm_bb_addr_map,.text._Z3foov{{$}}
 ; CHECK-NEXT:   .quad [[FOO_BEGIN]]
 
 
 define linkonce_odr dso_local i32 @_Z4fooTIiET_v() comdat {
   ret i32 0
 }
-;; Check we add .bb_addr_map section to a COMDAT group with the corresponding .text section if such a COMDAT exists.
+;; Check we add .llvm_bb_addr_map section to a COMDAT group with the corresponding .text section if such a COMDAT exists.
 ; CHECK:    .section .text._Z4fooTIiET_v,"axG",@progbits,_Z4fooTIiET_v,comdat
 ; CHECK-LABEL:  _Z4fooTIiET_v:
 ; CHECK-NEXT: [[FOOCOMDAT_BEGIN:.Lfunc_begin[0-9]+]]:
-; CHECK:    .section .bb_addr_map,"Go",@progbits,_Z4fooTIiET_v,comdat,.text._Z4fooTIiET_v{{$}}
+; CHECK:    .section .llvm_bb_addr_map,"Go",@llvm_bb_addr_map,_Z4fooTIiET_v,comdat,.text._Z4fooTIiET_v{{$}}
 ; CHECK-NEXT:   .quad [[FOOCOMDAT_BEGIN]]

llvm/test/CodeGen/X86/basic-block-sections-labels.ll

 ; CHECK-LABEL:  .LBB0_1:
 ; CHECK-LABEL:  .LBB_END0_1:
 ; CHECK-LABEL:  .LBB0_2:
 ; CHECK-LABEL:  .LBB_END0_2:
 ; CHECK-LABEL:  .LBB0_3:
 ; CHECK-LABEL:  .LBB_END0_3:
 ; CHECK-LABEL:  .Lfunc_end0:
 
-; CHECK:  .section  .bb_addr_map,"o",@progbits,.text
+; CHECK:  .section  .llvm_bb_addr_map,"o",@llvm_bb_addr_map,.text
 ; CHECK-NEXT: .quad .Lfunc_begin0
 ; CHECK-NEXT: .byte 4
 ; CHECK-NEXT: .uleb128 .Lfunc_begin0-.Lfunc_begin0
 ; CHECK-NEXT: .uleb128 .LBB_END0_0-.Lfunc_begin0
 ; CHECK-NEXT: .byte 0
 ; CHECK-NEXT: .uleb128 .LBB0_1-.Lfunc_begin0
 ; CHECK-NEXT: .uleb128 .LBB_END0_1-.LBB0_1
 ; CHECK-NEXT: .byte 0
 ; CHECK-NEXT: .uleb128 .LBB0_2-.Lfunc_begin0
 ; CHECK-NEXT: .uleb128 .LBB_END0_2-.LBB0_2
 ; CHECK-NEXT: .byte 1
 ; CHECK-NEXT: .uleb128 .LBB0_3-.Lfunc_begin0
 ; CHECK-NEXT: .uleb128 .LBB_END0_3-.LBB0_3
 ; CHECK-NEXT: .byte 5

llvm/test/MC/AsmParser/section_types.s

+## Verify that section types are correctly inferred from assembly input.
+# RUN: llvm-mc -triple i386-pc-linux-gnu -filetype=obj -o %t %s
+# RUN: llvm-readobj -S - < %t | FileCheck %s
+.section    .section1,"",@llvm_bb_addr_map
+.byte 1
+.section    .section2,"",@llvm_call_graph_profile
+.byte 1
+.section    .section3,"",@llvm_odrtab
+.byte 1
+.section    .section4,"",@llvm_linker_options
+.byte 1
+.section    .section5,"",@llvm_sympart
+.byte 1
+.section    .section6,"",@llvm_dependent_libraries
+.byte 1
+# CHECK:        Name: .section1
+# CHECK-NEXT:   Type: SHT_LLVM_BB_ADDR_MAP
+# CHECK:        Name: .section2
+# CHECK-NEXT:   Type: SHT_LLVM_CALL_GRAPH_PROFILE
+# CHECK:        Name: .section3
+# CHECK-NEXT:   Type: SHT_LLVM_ODRTAB
+# CHECK:        Name: .section4
+# CHECK-NEXT:   Type: SHT_LLVM_LINKER_OPTIONS
+# CHECK:        Name: .section5
+# CHECK-NEXT:   Type: SHT_LLVM_SYMPART
+# CHECK:        Name: .section6
+# CHECK-NEXT:   Type: SHT_LLVM_DEPENDENT_LIBRARIES