From to ~sircmpwn/hare-dev
From: Tobias Heider <me@tobhe.de> Storage is a union of values with different sizes, passing the contents unconditionally as int64 might work on amd64 but breaks on other archs. Since the type information is available we can use the correct union field for each type instead. Found the hard way trying to build this on big endian PowerPC. Signed-off-by: Tobias Heider <me@tobhe.de> --- src/check.c | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) [message trimmed]
From to ~sircmpwn/hare-dev
From: Tobias Heider <me@tobhe.de> Storage is a union of values with different sizes, passing the contents unconditionally as int64 might work on amd64 but breaks on other archs. Since the type information is available we can use the correct union field for each type instead. Found the hard way trying to build this on big endian PowerPC. Signed-off-by: Tobias Heider <me@tobhe.de> --- src/check.c | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) [message trimmed]
From Tobias Heider to ~mpu/qbe
--- tools/test.sh | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/tools/test.sh b/tools/test.sh index fa782c3..8c3802a 100755 --- a/tools/test.sh +++ b/tools/test.sh @@ -196,15 +196,17 @@ fi case "$1" in "all") fail=0 count=0 for t in $dir/../test/[!_]*.ssa [message trimmed]
From Tobias Heider to ~mpu/qbe
On Tue, Jan 23, 2024 at 05:38:41PM +0000, Ember Sawady wrote: > On Tue Jan 23, 2024 at 11:04 AM UTC, Tobias Heider wrote: > > Before: 14 test(s) failed! > > After: 14 test(s) of 51 failed! > > minor nit: "14 of 51 test(s) failed!" reads better to my ears Right, I agree. I'll send an update.
From Tobias Heider to ~mpu/qbe
--- This seems to be quite helpful when working on a new backend. Before: 14 test(s) failed! After: 14 test(s) of 51 failed! tools/test.sh | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/tools/test.sh b/tools/test.sh index fa782c3..b57a024 100755 --- a/tools/test.sh +++ b/tools/test.sh @@ -196,15 +196,17 @@ fi [message trimmed]
From Tobias Heider to ~sircmpwn/hare-dev
Storage is a union of values with different sizes, passing the contents unconditionally as int64 might work on amd64 but breaks on other archs. Since the type information is available we can use the correct union field for each type instead. Found the hard way trying to build this on big endian PowerPC. Signed-off-by: Tobias Heider <me@tobhe.de> --- src/check.c | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/src/check.c b/src/check.c [message trimmed]
From Tobias Heider to ~sircmpwn/hare-dev
On Sun, Dec 03, 2023 at 12:17:40PM +0100, Lorenz (xha) wrote: > hi, > > can someone who has experience with x86_64 assembly take a look at the > diff below? > > i am currently trying to get hare working with IBT (most stuff already > working with a qbe diff from tobhe). however, the longjump is not > working because we are trying to jump into the middle of the function > (where qbe won't generate an endbr64 instruction). > > however, IBT just checks indirect jumps and not returns afaik. the > following fixes tests::exit (which uses longjmp) on my machine with IBT > enabled but i am not sure if this is fine.
From Tobias Heider to ~mpu/qbe
--- This is needed to work with struct BTI enforcement as is the default now on OpenBSD. The instructions should evaluate to nops on non-supported hardware. The reason I use hint #34 instead of bti c for arm64 is that the gnu assembler doesn't like bti instructions unless it is explicitly enabled, see https://reviews.llvm.org/D81257 amd64/emit.c | 2 ++ arm64/emit.c | 2 ++ 2 files changed, 4 insertions(+) diff --git a/amd64/emit.c b/amd64/emit.c [message trimmed]
From Tobias Heider to ~mpu/qbe
Hi, OpenBSD has started to strictly enforce running with BTI/IBT where supported by the hardware. This patch adds endbr64/bti c instructions to the function entry points. I have used hint #34 for bti because the gnu assembler doesn't like bti instructions when they aren't explicitly enabled. This is similar to the apprach taken by llvm here: https://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20200601/790000.html On non-supported machines they should simply evaluate to nop.