Allow linking to system Zydis

[McSinyx]

Zydis 4 is available on most distributions (Debian, Fedora, Alpine, Arch, etc.). Linking with system library instead of vendoring a large codebase with an unknown amount of modification will make it possible to package E9Patch for downstream distribution.

I will add the vendoring build recipe in addition to this if wanted.

[GJDuck]

Linking with system library instead of vendoring a large codebase with an unknown amount of modification will make it possible to package E9Patch for downstream distribution.

This was a deliberate decision, as it freezes the disassembly semantics to a specific version, meaning that the behaviour of E9Tool/E9Patch does not change due to differences in the underlying version of Zydis. I am not sure if there is a better way of doing this.

[McSinyx]

it freezes the disassembly semantics to a specific version

Is the vendored Zydis version 4.0.0?

e9patch/contrib/zydis/include/Zydis/Zydis.h

Lines 73 to 105 in b6fee73

	#define ZYDIS_VERSION (ZyanU64)0x0004000000000000
	/* ---------------------------------------------------------------------------------------------- */
	/* Helper macros */
	/* ---------------------------------------------------------------------------------------------- */
	/**
	* Extracts the major-part of the zydis version.
	*
	* @param version The zydis version value
	*/
	#define ZYDIS_VERSION_MAJOR(version) (ZyanU16)(((version) & 0xFFFF000000000000) >> 48)
	/**
	* Extracts the minor-part of the zydis version.
	*
	* @param version The zydis version value
	*/
	#define ZYDIS_VERSION_MINOR(version) (ZyanU16)(((version) & 0x0000FFFF00000000) >> 32)
	/**
	* Extracts the patch-part of the zydis version.
	*
	* @param version The zydis version value
	*/
	#define ZYDIS_VERSION_PATCH(version) (ZyanU16)(((version) & 0x00000000FFFF0000) >> 16)
	/**
	* Extracts the build-part of the zydis version.
	*
	* @param version The zydis version value
	*/
	#define ZYDIS_VERSION_BUILD(version) (ZyanU16)((version) & 0x000000000000FFFF)

I am not sure if there is a better way of doing this.

Bundled dependencies are frown upon for maintenance and security reasons by most distributions, e.g. Debian, Fedora and Gentoo. Since you're working towards a production release (1.0.0), I suppose E9Patch being included in a production-ready environment is not exactly a non-goal.

You can declare the Zydis version officially supported by E9Patch and have both build recipes linking to bundled Zydis and a system one, similar to how it's been done for elfutils. I volunteer to work on that if welcomed.

To be fair, it is possible to just carry patches like the ones I attached here downstream, just that it's always nicer to have upstream support.

[GJDuck]

Yes, this is a good idea. We should figure out an "official" version of Zydis and link against a system version for a future distro version.

I can't recall which version of Zydis is included in E9Tool. I think it may have been a random commit.

Always updating to the "latest Zydis" will cause problems, as evidenced by some of the pull requests, where differences in Zydis versions cause the behaviour of E9Tool to change in various ways.

You are welcome to work on this.

[McSinyx]

Thanks, I've just pushed the build recipe for linking to system Zydis in make target all. A few side effects:

• all no longer assumes CXXFLAGS -O2 or strips the binaries. Most distributions actually do it, but let's defer that choice to them.
• release, debug and sanitize targets now cache e9patch and e9tool.

[GJDuck]

Does this keep the default build.sh intact? If so, I will merge.

[McSinyx]

Thanks, 0edefb9 should make build.sh work again. Please let me know if you prefer separate target(s) to clean artifacts from bundled libdw and Zydis.

[GJDuck]

Basically, the non-standard build.sh script should build the "classic" versions of E9Tool/E9Patch with the statically-linked local libraries. Then there should also be a standard make alternative that builds a "distro-friendly" version which dynamically links against the system version of the libraries. If this patch achieves this, then I am happy to merge.

Btw, would you be interested in adding E9Tool/E9Patch to standard distros (Debian, etc.)?

[McSinyx]

This patchset should achieve the listed requirements, with a slight issue: due to make's caching mechanism, alternating build between all/release/tool/debug would require a make clean in between (well, dev targets only differ at linking so rm e9patch e9tool would suffice while shuffling between release/tool/debug).

As for distribution, I'm currently only using Guix and plan to send a patch adding E9Patch to the mainline repo once this, GH-88 and GH-92 are merged and another release candidate is published. Downstream will have to carry a couple of patches for compatibility with Zydis 4.1.0 (GH-93, GH-95, and disabling tests mentioned in in GH-96 and GH-97). For reference, here is the package definition in my development environment.

Once the downstream package meets the standard of Guix, similar packaging (including downstream patches) can be done for e.g. Debian and Fedora, but unfortunately that's outside of my interest.

[GJDuck]

Thanks!

Debian and Fedora, but unfortunately that's outside of my interest.

No problem, just checking.