While using llvm-objdump I noticed that for the pc-rel branching instructions (jmp/br/call) it prints the immediate value encoded in the instruction, as opposed to the target address like binutils does.
I’ve created a patch (https://reviews.llvm.org/D71453) that tries to match the output of those instructions with binutils, my first attempt to contribute. Since I modify the target specific 'InstPrinter’s I only did it (initially) for the targets that have llvm-objdump tests, and also I assume InstPrinter might be used in more components other than objdump, therefore I would like to kindly ask for you feedback.
4005af: 0f 8f 35 00 00 00 jg 4005ea <main+0x8a>
4005af: 0f 8f 35 00 00 00 jg 0x35 <main+0x8a>
Thank you for your patch. You’ll see that I already reviewed it before seeing this email and have just added a couple of others to the patch as reviewers who I know work in this area.
Functional changes that improve compatibility with the GNU equivalent binutil are always welcome. The general opinion is that we should aim for compatibility except for extreme cases where what GNU does is clearly a bug or it doesn’t matter (e.g. in llvm-objcopy, our output is sometimes slightly different, but we aim for the same semantic behaviour).
I’m not really familiar with how InstPrinter is used outside llvm-objdump. You should make sure to run the
check-all build target to ensure there is no other testing that relies on the behaviour you have changed.
I don’t think we want to be in a place where the behaviour is different across different targets. Consequently, I’d make sure you check and change the behaviour for the other targets too, and add testing for those changes.
Let us know if you have any more questions!