build system: move build.sh and install.sh to Makefile

[milahu]

low priority...

currently, packaging e9patch is too verbose

ideally, build and install should work with make && sudo make install

ideally, the build should work offline by default, make should download and unpack the zydis and zycore sources optionally, make should accept ZYDIS_SOURCE and ZYCORE_SOURCE envs to copy the unpacked sources from these paths

currently, ZydisExportConfig.h and ZycoreExportConfig.h are generated by build.sh these should be stored as *.h.in files and copied to zydis/include/

[GJDuck]

Yes, the build system is slightly unconventional and could be normalized. This project really does not have any dependencies (aside from zydis, which requires a specific version to be statically linked in), which is why a simple build script suffices without needing things like autotools or cmake, etc. Perhaps a more conventional build process could be supported in parallel.

[McSinyx]

zydis, which requires a specific version to be statically linked in

Could you elaborate on the reason behind this? I'm trying to package e9Patch for Guix and dependency vendoring is a no-go for security reasons (not just Guix but also most distributions). It's perfectly fine if E9Patch relies on a specific version of Zydis (with some extra patches) though.

Can't test on non-POSIX systems, but on normal systems both vendored dependencies (elfutils and zydis+zycore) are installed to standard locations so a C compiler can find the libraries with -ldw -lZydis (zlib is already linked this way) and the headers naturally (with a tiny change into #include <elfutils/libdw.h>).

[GJDuck]

Could you elaborate on the reason behind this?

1. For Zydis, the idea was to "fix" the behavior of the disassembler, so that innocent changes to Zydis would not cause (possible subtle) changes in E9Tool matching/patching behavior.
2. For libdw, E9tool only needs a relatively small part of the library (line number parsing code), so only that specific functionality was included (& statically linked).
3. For libz, it is pulled in by libdw (ELF compressed sections?). It is stable and ubiquitous, so not really a problem.

So I think it would be problematic to change the version of Zydis. For libdw, it would be a relatively small effort to use dynamic linking and the system libdw, and this could be achieved by updating the Makefile to support this option. In fact, the Makefile should probably be updated to use conventional targets and build options by default, and can still support unconventional builds via non-standard targets.

[GJDuck]

I've added a more traditional build:

    $ make
    $ make install

This is in addition to the old build.sh and install.sh scripts.

Perhaps this will help. Please let me know if anything else is needed.

[milahu]

thanks!

almost there, see my e9patch.nix and Makefile

dependency: zydis.nix

make install fails with install: cannot create directory '/usr': Permission denied fixed by using $(prefix) in Makefile

e9compile does not find stdlib.c typo: example -> examples

broken colors in e9compile (deja vu...) fixed by sed -i -E s/'="\\033\[([0-9]+)m"'/"=$'\\\\033[\1m'"/ e9compile.sh

type warning in src/e9tool/e9cfg.cpp - %zu -> %u

not sure if the segfault is expected ...

$ ./result/bin/e9compile result/share/e9tool/examples/bounds.c
gcc -fno-stack-protector -fno-builtin -fno-exceptions -fpie -O2 -Wno-unused-function -U_FORTIFY_SOURCE -mno-mmx -mno-sse -mno-avx -mno-avx2 -mno-avx512f -msoft-float -mstringop-strategy=loop -fno-tree-vectorize -fomit-frame-pointer -I /nix/store/by9kqjzr4pbikqma6scqwrv5a5h7zm5c-e9patch-1.0.0-rc10-unstable-2024-08-07/share/e9compile/include/ -c -Wall result/share/e9tool/examples/bounds.c
gcc bounds.o -o bounds -pie -nostdlib -Wl,-z -Wl,max-page-size=4096 -Wl,-z -Wl,norelro -Wl,-z -Wl,stack-size=0 -Wl,--export-dynamic -Wl,--entry=0x0 -Wl,--strip-all

$ ./bounds
Segmentation fault (core dumped)

[GJDuck]

Thanks, I will check what changes are necessary.

not sure if the segfault is expected ...

Yes, the SEGV is not ideal, but it is expected. The e9compile script emits a binary executable that is compatible with E9Tool instrumentation, but is not designed to be run directly.

[GJDuck]

I assume this has been resolved.

[milahu]

colors are still broken note the $ before '...' aka ansi c quoted strings

$ echo '\033[31mred\033[0m'
\033[31mred\033[0m

$ echo -e '\033[31mred\033[0m'
red

$ echo 'RED="\033[31m"' | sed -E s/'="\\033\[([0-9]+)m"'/"=$'\\\\033[\1m'"/
RED=$'\033[31m'

$ echo $'\033[31mred\033[0m'
red