aboutsummaryrefslogtreecommitdiff
path: root/sim
diff options
context:
space:
mode:
authorJose E. Marchesi <jose.marchesi@oracle.com>2023-07-15 00:50:14 +0200
committerJose E. Marchesi <jose.marchesi@oracle.com>2023-07-21 12:20:40 +0200
commitd218e7fedc74d67837d2134120917f4ac877454c (patch)
treedf890450897d7540385d9d7b5926ab35cbafb120 /sim
parent1c850ca80dc53ffa2bfadabbacda231c941dee76 (diff)
downloadgdb-d218e7fedc74d67837d2134120917f4ac877454c.zip
gdb-d218e7fedc74d67837d2134120917f4ac877454c.tar.gz
gdb-d218e7fedc74d67837d2134120917f4ac877454c.tar.bz2
DesCGENization of the BPF binutils port
CGEN is cool, but the BPF architecture is simply too bizarre for it. The weird way of BPF to handle endianness in instruction encoding, the weird C-like alternative assembly syntax, the weird abuse of multi-byte (or infra-byte) instruction fields as opcodes, the unusual presence of opcodes beyond the first 32-bits of some instructions, are all examples of what makes it a PITA to continue using CGEN for this port. The bpf.cpu file is becoming so complex and so nested with p-macros that it is very difficult to read, and quite challenging to update. Also, every time we are forced to change something in CGEN to accommodate BPF requirements (which is often) we have to do extensive testing to make sure we do not break any other target using CGEN. This is getting un-maintenable. So I have decided to bite the bullet and revamp/rewrite the port so it no longer uses CGEN. Overall, this involved: * To remove the cpu/bpf.{cpu,opc} descriptions. * To remove the CGEN generated files. * To replace the CGEN generated opcodes table with a new hand-written opcodes table for BPF. * To replace the CGEN generated disassembler wih a new disassembler that uses the new opcodes. * To replace the CGEN generated assembler with a new assembler that uses the new opcodes. * To replace the CGEN generated simulator with a new simulator that uses the new opcodes. [This is pushed in GDB in another patch.] * To adapt the build systems to the new situation. Additionally, this patch introduces some extensions and improvements: * A new BPF relocation BPF_RELOC_BPF_DISP16 plus corresponding ELF relocation R_BPF_GNU_64_16 are added to the BPF BFD port. These relocations are used for section-relative 16-bit offsets used in load/store instructions. * The disassembler now has support for the "pseudo-c" assembly syntax of BPF. What dialect to use when disassembling is controlled by a command line option. * The disassembler now has support for dumping instruction immediates in either octal, hexadecimal or decimal. The used output base is controlled by a new command-line option. * The GAS BPF test suite has been re-structured and expanded in order to test the disassembler pseudoc syntax support. Minor bugs have been also fixed there. The assembler generic tests that were disabled for bpf-*-* targets due to the previous implementation of pseudoc syntax are now re-enabled. Additional tests have been added to test the new features of the assembler. .dump files are no longer used. * The linker BPF test suite has been adapted to the command line options used by the new disassembler. The result is very satisfactory. This patchs adds 3448 lines of code and removes 10542 lines of code. Tested in: * Target bpf-unknown-none with 64-bit little-endian host and 32-bit little-endian host. * Target x86-64-linux-gnu with --enable-targets=all Note that I have not tested in a big-endian host yet. I will do so once this lands upstream so I can use the GCC compiler farm. I have not included ChangeLog entries in this patch: these would be massive and not very useful, considering this is pretty much a rewrite of the port. I beg the indulgence of the global maintainers.
Diffstat (limited to 'sim')
0 files changed, 0 insertions, 0 deletions