[RISCV] Incomplete llvm-objdump disassembly when using LTO

[andcarminati]

I detected the following problem related to LTO. Considering the following use case:

A simple C program :

int __attribute__((used)) main(){
}

If we build it with:

clang  --target=riscv32 -march=rv32imafdc -mabi=ilp32d  -O1 sample.c -o sample.elf 

We get with llvm-objdump:

Disassembly of section .text:

000110d4 <main>:
   110d4: 01 45         li      a0, 0
   110d6: 82 80         ret

But, if we build it with:

clang  --target=riscv32 -march=rv32imafdc -mabi=ilp32d  -O1 sample.c -o sample.elf -flto

Then we have:

Disassembly of section .text:

000110d4 <main>:
   110d4: 01 45         <unknown>
   110d6: 82 80         <unknown>

It seems that it is related to the ELF attributes, under LTO they became incomplete in the final elf. The disassembler cannot decode because the feature flags are not present in the MCSubtarget.

[llvmbot]

@llvm/issue-subscribers-backend-risc-v

Author: Andreu Carminati (andcarminati)

I detected the following problem related to LTO. Considering the following use case:

A simple C program :

int __attribute__((used)) main(){
}

If we build it with:

clang  --target=riscv32 -march=rv32imafdc -mabi=ilp32d  -O1 sample.c -o sample.elf 

We get with llvm-objdump:

Disassembly of section .text:

000110d4 <main>:
   110d4: 01 45         li      a0, 0
   110d6: 82 80         ret

But, if we build it with:

clang  --target=riscv32 -march=rv32imafdc -mabi=ilp32d  -O1 sample.c -o sample.elf -flto

Then we have:

Disassembly of section .text:

000110d4 <main>:
   110d4: 01 45         <unknown>
   110d6: 82 80         <unknown>

It seems that it is related to the ELF attributes, under LTO they became incomplete in the final elf. The disassembler cannot decode because the feature flags are not present in the MCSubtarget.

[llvmbot]

@llvm/issue-subscribers-tools-llvm-objdump

Author: Andreu Carminati (andcarminati)

I detected the following problem related to LTO. Considering the following use case:

A simple C program :

int __attribute__((used)) main(){
}

If we build it with:

clang  --target=riscv32 -march=rv32imafdc -mabi=ilp32d  -O1 sample.c -o sample.elf 

We get with llvm-objdump:

Disassembly of section .text:

000110d4 <main>:
   110d4: 01 45         li      a0, 0
   110d6: 82 80         ret

But, if we build it with:

clang  --target=riscv32 -march=rv32imafdc -mabi=ilp32d  -O1 sample.c -o sample.elf -flto

Then we have:

Disassembly of section .text:

000110d4 <main>:
   110d4: 01 45         <unknown>
   110d6: 82 80         <unknown>

It seems that it is related to the ELF attributes, under LTO they became incomplete in the final elf. The disassembler cannot decode because the feature flags are not present in the MCSubtarget.

[topperc]

I thought we emitted a mapping symbol giving the ISA for each function. See https://reviews.llvm.org/D153260 This is more flexible to allow different functions to have incompatible extensions. Does llvm-objdump not know how to use the mapping symbol or are we not emitting them in LTO?

@MaskRay @jrtc27 @kito-cheng

[andcarminati]

I thought we emitted a mapping symbol giving the ISA for each function. See https://reviews.llvm.org/D153260 This is more flexible to allow different functions to have incompatible extensions. Does llvm-objdump not know how to use the mapping symbol or are we not emitting them in LTO?

@MaskRay @jrtc27 @kito-cheng

Hi @topperc.

I think the problem is that the way the disassembler works, that is in some way incompatible with per-function flags. For example, the constructor will receive MCSubtargetInfo, not the decoding methods:

  RISCVDisassembler(const MCSubtargetInfo &STI, MCContext &Ctx,
                    MCInstrInfo const *MCII)
      : MCDisassembler(STI, Ctx), MCII(MCII) {}

We may receive a subset of feature flags in this case, and if we receive a partial string as an attribute, we will not be able to decode all extensions.

For example, without LTO we get this information with the ELF:

BuildAttributes {
  FormatVersion: 0x41
  Section 1 {
    SectionLength: 61
    Vendor: riscv
    Tag: Tag_File (0x1)
    Size: 51
    FileAttributes {
      Attribute {
        Tag: 4
        Value: 16
        TagName: stack_align
        Description: Stack alignment is 16-bytes
      }
      Attribute {
        Tag: 5
        TagName: arch
        Value: rv32i2p1_m2p0_a2p1_f2p2_d2p2_c2p0_zicsr2p0
      }
    }
  }
}

With LTO, this one:

BuildAttributes {
  FormatVersion: 0x41
  Section 1 {
    SectionLength: 27
    Vendor: riscv
    Tag: Tag_File (0x1)
    Size: 17
    FileAttributes {
      Attribute {
        Tag: 4
        Value: 16
        TagName: stack_align
        Description: Stack alignment is 16-bytes
      }
      Attribute {
        Tag: 5
        TagName: arch
        Value: rv32i2p1 <- this value will be used for MCSubtargetInfo for disassembling.
      }
    }
  }
}

Regards

[topperc]

I guess LLVM doesn't contain code to emit the ISA with the mapping symbol?

[andcarminati]

Hi @topperc,

According to the mapping symbol emission, I found the following (a0d8a53):

[...]
This patch implements mapping symbols for RISC-V, copying the
implementation mostly from the AArch64 target.

Note that the $x<ISA> mapping symbol, indicating an instruction
sequence with a specific ISA extension, is not implemented by this
patch. As far as I can tell, binutils doesn't implement this yet either.

Note that this patch uses the same symbol naming convention as the
AArch64 target: always use $x.i and $d.i (where i is a
monotonically increasing counter). This differs from binutils where all
symbols are named $x or $d (causing multiple symbol having the same
name). I'm not not sure whether it makes more sense to avoid duplicate
symbol names or be consistent with binutils.
[...]

It seems that we lack this ISA part.

[andcarminati]

Hi @topperc, considering that we are not emitting the ISA part yet, I already have one proposal for this: https://github.com/llvm/llvm-project/compare/main...andcarminati:llvm-project:rv-complete-mapping-symbols?expand=1

After this fix, we can implement the decoding part in llvm-objdump.