aboutsummaryrefslogtreecommitdiff
path: root/tools/add-cfi.i386.awk (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Fix the build system.EuAndreh2024-01-051-209/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The improvements are: - use most of the default "Makefile" for standard packaging; - also use the default ".gitignore" with for the derived assets; - don't impose so many $CFLAGS on the user. GCC still needs to be given the `-ffreestanding` flag explicitly for us to get a good binary; - stop using ad-hoc tools/* scripts, and avoid the code-generation anti-pattern overall on the build. Some of the generated files were checked-in, and some were removed; - remove empty files; - use POSIX make(1) over gmake; - add fuzz targets; - partial "install" and "uninstall" targets; - complete "clean" target. The shortcomings are: - only working on x86_64. More platforms coming soon; - code is still messy: way too many warnings, GNU/BSD specific extensions, inline assembly, and all kinds of unportable code; - still only works with GCC and GCC-like compilers, and completly fails with tcc(1) and cproc(1); - the `deps.mk` file is being maintained manually. As I work on the source files I'll finish automating its generation with `mkdeps.sh`; - still seems to be coupled with Linux; - still is missing tests setup; - still uses `#include <$NAME.h>` instead of the correct `#include "$NAME.h"` form. The generated libgrovel.a did match the previous lib/libc.a 100%.
* fix incorrect escaping in add-cfi.*.awk scriptsWill Dietz2020-01-201-1/+1
| | | | gawk 5 complains.
* recognize partial register operands in i386 CFI generationAlex Dowad2015-10-131-10/+19
|
* fix misinterpretation of indexed memory operand in i386 CFI generationAlex Dowad2015-10-131-1/+1
| | | | | a register used as an index in the memory destination of a mov instruction was wrongly interpreted as the destination of the mov.
* fix misinterpretation of operand order in i386 CFI generationAlex Dowad2015-10-131-5/+5
| | | | binary ops like ADD, AND, etc. modify the 2nd operand, not 1st.
* fix instruction matching errors in i386 CFI generationAlex Dowad2015-10-081-3/+3
| | | | | | fdiv and fmul instructions were wrongly matched by the rules for integer div and mul instructions, leading to incorrect conclusions about register values being clobbered.
* factor common awk functions for CFI generation scripts into new fileAlex Dowad2015-10-081-27/+0
| | | | | | There is a lot which could be common between i386 and x86_64, but none of it will be useful for any other arch. These should be useful for all archs, however.
* Build process uses script to add CFI directives to x86 asmAlex Dowad2015-08-261-0/+227
Some functions implemented in asm need to use EBP for purposes other than acting as a frame pointer. (Notably, it is used for the 6th argument to syscalls with 6 arguments.) Without frame pointers, GDB can only show backtraces if it gets CFI information from a .debug_frame or .eh_frame ELF section. Rather than littering our asm with ugly .cfi directives, use an awk script to insert them in the right places during the build process, so GDB can keep track of where the current stack frame is relative to the stack pointer. This means GDB can produce beautiful stack traces at any given point when single-stepping through asm functions. Additionally, when registers are saved on the stack and later overwritten, emit ..cfi directives so GDB will know where they were saved relative to the stack pointer. This way, when you look back up the stack from within an asm function, you can still reliably print the values of local variables in the caller. If this awk script were to understand every possible wild and crazy contortion that an asm programmer can do with the stack and registers, and always emit the exact ..cfi directives needed for GDB to know what the register values were in the preceding stack frame, it would necessarily be as complex as a full x86 emulator. That way lies madness. Hence, we assume that the stack pointer will _only_ ever be adjusted using push/pop or else add/sub with a constant. We do not attempt to detect every possible way that a register value could be saved for later use, just the simple and common ways. Thanks to Szabolcs Nagy for suggesting numerous improvements to this code.