[PATCH] D70541: [DWARF][RISCV] Test resolving of RISC-V relocations

Thu Dec 5 11:30:34 PST 2019

MaskRay accepted this revision.
MaskRay added inline comments.
This revision is now accepted and ready to land.

================
Comment at: llvm/test/tools/llvm-dwarfdump/RISCV/riscv-relocs.yaml:19
+    # DW_AT_high_pc and DW_AT_stmt_list.
+    Content:         280000000400000000000801000000000C000000002F00000000000000000042000000000000000100000000280000000400000000000801000000000C000000002F00000000000000000042000000000000000200000000280000000400000000000801000000000C000000002F00000000000000000042000000000000000300000000280000000400000000000801000000000C000000002F00000000000000000042000000000000000400000000280000000400000000000801000000000C000000002F00000000000000000042000000000000000500000000280000000400000000000801000000000C000000002F00000000000000000042000000000000000600000000280000000400000000000801000000000C000000002F00000000000000000042000000000000000700000000280000000400000000000801000000000C000000002F00000000000000000042420000000000000800000000280000000400000000000801000000000C000000002F00000000000000000042420000000000000900000000280000000400000000000801000000000C000000002F00000000000000000042424242000000000A00000000280000000400000000000801000000000C000000002F00000000000000000042424242000000000B00000000280000000400000000000801000000000C000000002F00000000000000000042424242424242000C00000000280000000400000000000801000000000C000000002F00000000000000000042424242424242000D00000000280000000400000000000801000000000C000000002F00000000000000000042000000000000000e00000000
+  - Name:            .rela.debug_info
----------------
luismarques wrote:
> MaskRay wrote:
> > luismarques wrote:
> > > MaskRay wrote:
> > > > luismarques wrote:
> > > > > MaskRay wrote:
> > > > > > 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.
> > > > > 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).
> > > > 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
> > > > ```
> > > 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 ?
> > > 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).
> > 
> > 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?
> 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.
>  (e.g. the base value to which relocations are applied on top of).
>
> you can't just say (AFAIK) "have the value X here and apply the relocation Y on top of it".

To have a different base value is a sufficiently strong argument to keep it as an opaque 'Content' field in a YAML test. LG!

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D70541/new/

https://reviews.llvm.org/D70541