<div dir="ltr">Thanks for the explanation. Why not just always enable all of them during objdump? If the binary wasn't compiled with the M instruction it won't be present in the machine code right?</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jan 30, 2020 at 3:46 AM Simon Cook via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Sam,<br>
<br>
I'm wondering in this case whether for the disassembler we should be<br>
using a different default that explicitly enables all the standard<br>
extensions to match what it looks like GNU binutils objdump is doing (I<br>
note we already do this for extracting compressed support out of the<br>
e_flags field in ElfObjectFile.cpp)?<br>
<br>
I know there is the .riscv.attributes section that gas now adds that<br>
stores this information, which we could use at some point to autoenable<br>
the correct feature subset, but it looks like LLVM doesn't yet generate<br>
or support parsing that. Do we know if anyone has been working on or<br>
plans on adding support for that.<br>
<br>
Thanks,<br>
Simon<br>
<br>
On 30/01/2020 10:56, Sam Elliott via llvm-dev wrote:<br>
> For your architecture (rv32imc), you’ll need to pass `-mattr=+m,+c` which allows llvm-objdump to disassemble both the M and the C RISC-V extensions.<br>
> <br>
> For more general background: `-mattr=` takes a comma separated list of features to enable (+feature) or disable (-feature). The RISC-V backend has one “feature” per implemented RISC-V architectural extension, each named using the lower case letter that corresponds to the extension in the RISC-V specification. LLVM chooses a default set of features based on the triple, but for `riscv32` (which expands to `riscv32-unknown-elf`) we enable the features that correspond to `rv32i` only.<br>
> <br>
> I hope this helps you out! It is good to know that this is somewhere the RISC-V backend could improve its documentation.<br>
> <br>
> Sam<br>
> <br>
> <br>
>> On 30 Jan 2020, at 2:56 am, Pieter Kapsenberg via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
>><br>
>> I built llvm + clang from source, a github clone from today:<br>
>> clang version 11.0.0 (<a href="https://github.com/llvm/llvm-project.git" rel="noreferrer" target="_blank">https://github.com/llvm/llvm-project.git</a> 91aa67bf290bc7f877b1b90128284863bc31aa43)<br>
>><br>
>> I compiled a small program:<br>
>> #include <stdint.h><br>
>><br>
>> int main() {<br>
>> uint8_t a = 2;<br>
>> uint8_t b = 5;<br>
>> uint8_t c = a * b;<br>
>> }<br>
>> $ clang -c -target riscv32 -march=rv32imc -g main.c<br>
>> Works fine.<br>
>><br>
>> The dumped assembly seems to not know about the multiply instruction - is that expected? See offset 1e in the listing below. Happily, the opcode value does appear to match the MUL instruction.<br>
>><br>
>> $ llvm-objdump -S main.o<br>
>> main.o: file format ELF32-riscv<br>
>><br>
>><br>
>> Disassembly of section .text:<br>
>><br>
>> 00000000 .text:<br>
>> /usr/local/google/home/pkapsenb/work/llvm-project/build/bin/llvm-objdump: warning: 'main.o': failed to parse debug information for main.o<br>
>> 0: 01 00 nop<br>
>><br>
>> 00000002 main:<br>
>> ; int main() {<br>
>> 2: 41 11 addi sp, sp, -16<br>
>> 4: 06 c6 sw ra, 12(sp)<br>
>> 6: 22 c4 sw s0, 8(sp)<br>
>> 8: 00 08 addi s0, sp, 16<br>
>> a: 09 45 addi a0, zero, 2<br>
>> ; uint8_t a = 2;<br>
>> c: a3 0b a4 fe sb a0, -9(s0)<br>
>> 10: 15 45 addi a0, zero, 5<br>
>> ; uint8_t b = 5;<br>
>> 12: 23 0b a4 fe sb a0, -10(s0)<br>
>> ; uint8_t c = a * b;<br>
>> 16: 03 05 74 ff lb a0, -9(s0)<br>
>> 1a: 83 05 64 ff lb a1, -10(s0)<br>
>> 1e: 33 05 b5 02 <unknown><br>
>> 22: a3 0a a4 fe sb a0, -11(s0)<br>
>> 26: 01 45 mv a0, zero<br>
>> ; }<br>
>> 28: 22 44 lw s0, 8(sp)<br>
>> 2a: b2 40 lw ra, 12(sp)<br>
>> 2c: 41 01 addi sp, sp, 16<br>
>> 2e: 82 80 ret<br>
>> _______________________________________________<br>
>> LLVM Developers mailing list<br>
>> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
>> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
> <br>
> --<br>
> Sam Elliott<br>
> Software Developer - LLVM<br>
> lowRISC CIC<br>
> --<br>
> <br>
> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
> <br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>