This patch adds an object file (in yaml format) with a synthetic .debug_info section which we use to test that the supported RISC-V relocations are properly resolved.
Details
Details
Diff Detail
Diff Detail
Event Timeline
| llvm/test/tools/llvm-dwarfdump/RISCV/riscv-relocs.yaml | ||
|---|---|---|
| 19 | For this test, I feel that the opaque content makes the YAML test worse than an assembly test. You can use llvm-readelf -r or llvm-readobj -r to check the presence of intended relocations. | |
| llvm/test/tools/llvm-dwarfdump/RISCV/riscv-relocs.yaml | ||
|---|---|---|
| 19 | It's not ideal but I don't think we can have an assembly test file we can process with all of the relocations we can resolve. (The goal is to check that they are correctly resolved, not that they are present). | |
| llvm/test/tools/llvm-dwarfdump/RISCV/riscv-relocs.yaml | ||
|---|---|---|
| 19 | The opaque and length Content makes the test very difficult to modify. Neither does it explain what each octet does. Assembly augmented with comments will be easier to understand and modify, e.g. .byte 8 # Address size .byte 0 # Segment selector size .long 0 # Offset entry count | |
Comment Actions
- Adds instructions for (re)creating/extending the binary blobs inside .debug_info and .debug_abbrev;
- Simplifies the content of those sections to have only the fields we are interested in.
| llvm/test/tools/llvm-dwarfdump/RISCV/riscv-relocs.yaml | ||
|---|---|---|
| 19 | Changing the test to be an assembly file proved incompatible with adding all of the required relocations (if you know of a way to do it please say so). So instead I added an assembly file as a comment, which documents the binary blobs and allows people to easily recreate and extend the individual relocation tests below. Does that sufficiently address your concerns @MaskRay ? | |
| llvm/test/tools/llvm-dwarfdump/RISCV/riscv-relocs.yaml | ||
|---|---|---|
| 19 |
What relocation types cannot be represented by assembly? If there were any, I would think that psABI defined some relocation types that were not actually used in toolchains. If only one or two relocation types that cannot be represented but you do want to test them, how about just creating a separate test? | |
| llvm/test/tools/llvm-dwarfdump/RISCV/riscv-relocs.yaml | ||
|---|---|---|
| 19 | While some RISC-V relocations you can emit explicitly (e.g. %pcrel_hi) many of them you only get indirectly as the result of filling in some fields in debug sections and so on. Doing that doesn't seem to allow enough control over the contents of the ELF file (e.g. the base value to which relocations are applied on top of). I explored creating a .rela.debug_info section in the assembly file with the relocation entry fields manually specified but the assembler doesn't play nice, so that section isn't recognized as a proper relocation section. So that's what I meant, unlike when you use a yaml object file you can't just say (AFAIK) "have the value X here and apply the relocation Y on top of it". That's why it seems to me that the yaml file is the way to go, but if you know of a way to solve that then I have no problem with changing the test to use just an assembly file. | |
| llvm/test/tools/llvm-dwarfdump/RISCV/riscv-relocs.yaml | ||
|---|---|---|
| 19 |
To have a different base value is a sufficiently strong argument to keep it as an opaque 'Content' field in a YAML test. LG! | |
For this test, I feel that the opaque content makes the YAML test worse than an assembly test. You can use llvm-readelf -r or llvm-readobj -r to check the presence of intended relocations.