Re: gnustep/libobjc2 and BTI (was: Re: x11/gnustep/libobjc2 failed to build)

2024-03-09 Thread Sebastian Reitenbach 
Sure, fine with me, OK, sebastia@


Missing signature 

> On 8. Mar 2024, at 17:05, Stuart Henderson  wrote:
> 
> Something more than the libffi fix is indeed needed for gnustep on
> arm64, building x11/gnustep/back trips SIGILL when running plmerge (from
> gnustep-base) as part of the build.
> 
> I propose using USE_NOBTCFI-aarch64 (to link with -z nobtcfi on aarch64)
> for now on this set of ports, I think that's good enough for release.
> With this, oolite runs (kind-of important for an Acorn-derived system
> for historical reasons ;) and I can crash into things as well as I can
> on amd64.
> 
> $ doas egdb 
> /usr/local/bin/plmerge plmerge.core
> GNU gdb (GDB) 9.2
> Copyright (C) 2020 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later 
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
> Type "show copying" and "show warranty" for details.
> This GDB was configured as "aarch64-unknown-openbsd7.5".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> .
> Find the GDB manual and other documentation resources online at:
>.
> 
> For help, type "help".
> Type "apropos word" to search for commands related to "word"...
> Reading symbols from /usr/local/bin/plmerge...
> Reading symbols from /usr/local/bin/.debug/plmerge.dbg...
> [New process 288319]
> btCore was generated by `plmerge'.
> Program terminated with signal SIGILL, Illegal instruction.
> #0  -[NSBundle release] (self=0xad1ea1f58, _cmd=) at 
> NSBundle.m:2057
> 2057- (oneway void) release
> (gdb) bt
> #0  -[NSBundle release] (self=0xad1ea1f58, _cmd=) at 
> NSBundle.m:2057
> #1  0x000af6786cbc in release(objc_object*) () from 
> /usr/local/lib/libobjc2.so.3.0
> #2  0x000af6786b7c [PAC] in emptyPool(arc_tls*, void*) () from 
> /usr/local/lib/libobjc2.so.3.0
> #3  0x000af6786938 [PAC] in objc_autoreleasePoolPop () from 
> /usr/local/lib/libobjc2.so.3.0
> #4  0x000a975aa4fc [PAC] in -[NSAutoreleasePool dealloc] 
> (self=0xabd627908, _cmd=0xa978b0778 ) at 
> NSAutoreleasePool.m:571
> #5  0x000601345908 [PAC] in gnustep_base_user_main (argc=, 
> argv=, env=) at plmerge.m:139
> #6  0x000601344eb8 [PAC] in _start ()
> 
> 
> Index: games/oolite/Makefile
> ===
> RCS file: /cvs/ports/games/oolite/Makefile,v
> diff -u -p -r1.28 Makefile
> --- games/oolite/Makefile26 Sep 2023 09:41:39 -1.28
> +++ games/oolite/Makefile8 Mar 2024 15:54:40 -
> @@ -1,7 +1,7 @@
> COMMENT=space combat and trading game in the style of Elite
> 
> VERSION=1.73.4
> -REVISION =18
> +REVISION =19
> DISTNAME=oolite-dev-source-${VERSION}
> PKGNAME=oolite-${VERSION}
> CATEGORIES=games
> Index: www/sogo/Makefile
> ===
> RCS file: /cvs/ports/www/sogo/Makefile,v
> diff -u -p -r1.111 Makefile
> --- www/sogo/Makefile14 Jan 2024 20:49:18 -1.111
> +++ www/sogo/Makefile8 Mar 2024 15:54:40 -
> @@ -3,6 +3,7 @@ COMMENT =web based groupware server
> VERSION =5.9.1
> DISTNAME =SOGo-${VERSION}
> PKGNAME =sogo-${VERSION}
> +REVISION =0
> 
> SHARED_LIBS +=GDLContentStore 3.0
> SHARED_LIBS +=NGCards3.1
> Index: www/sope/Makefile
> ===
> RCS file: /cvs/ports/www/sope/Makefile,v
> diff -u -p -r1.99 Makefile
> --- www/sope/Makefile14 Jan 2024 20:40:45 -1.99
> +++ www/sope/Makefile8 Mar 2024 15:54:40 -
> @@ -7,6 +7,9 @@ DISTNAME =SOPE-${VERSION}
> PKGNAME-main =sope-${VERSION}
> PKGNAME-mysql =sope-mysql-${VERSION}
> PKGNAME-postgres =sope-postgres-${VERSION}
> +REVISION-main =0
> +REVISION-mysql =0
> +REVISION-postgres =0
> 
> SO_MAJOR=6
> SO_MINOR=0
> Index: x11/gnustep/gnustep.port.mk
> ===
> RCS file: /cvs/ports/x11/gnustep/gnustep.port.mk,v
> diff -u -p -r1.41 gnustep.port.mk
> --- x11/gnustep/gnustep.port.mk27 Sep 2023 20:37:07 -1.41
> +++ x11/gnustep/gnustep.port.mk8 Mar 2024 15:54:40 -
> @@ -1,6 +1,18 @@
> # until tested on others
> ONLY_FOR_ARCHS ?=${LLD_ARCHS}
> 
> +USE_NOBTCFI-aarch64= Yes
> +# Program terminated with signal SIGILL, Illegal instruction.
> +# #0  -[NSBundle release] (self=0x14704af2d8, _cmd=) at 
> NSBundle.m:2057
> +# #1  0x001565473cbc in release(objc_object*) () from 
> /usr/local/lib/libobjc2.so.3.0
> +# #2  0x001565473ac8 [PAC] in emptyPool(arc_tls*, void*) () from 
> /usr/local/lib/libobjc2.so.3.0
> +# #3  0x001565473938 [PAC] in objc_autoreleasePoolPop () from 
> /usr/local/lib/libobjc2.so.3.0
> +# #4  0x001496a7553c [PAC

Re: gnustep/libobjc2 and BTI (was: Re: x11/gnustep/libobjc2 failed to build)

2024-03-08 Thread Stuart Henderson 
Something more than the libffi fix is indeed needed for gnustep on
arm64, building x11/gnustep/back trips SIGILL when running plmerge (from
gnustep-base) as part of the build.

I propose using USE_NOBTCFI-aarch64 (to link with -z nobtcfi on aarch64)
for now on this set of ports, I think that's good enough for release.
With this, oolite runs (kind-of important for an Acorn-derived system
for historical reasons ;) and I can crash into things as well as I can
on amd64.

$ doas egdb 
/usr/local/bin/plmerge plmerge.core
GNU gdb (GDB) 9.2
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "aarch64-unknown-openbsd7.5".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/local/bin/plmerge...
Reading symbols from /usr/local/bin/.debug/plmerge.dbg...
[New process 288319]
btCore was generated by `plmerge'.
Program terminated with signal SIGILL, Illegal instruction.
#0  -[NSBundle release] (self=0xad1ea1f58, _cmd=) at 
NSBundle.m:2057
2057- (oneway void) release
(gdb) bt
#0  -[NSBundle release] (self=0xad1ea1f58, _cmd=) at 
NSBundle.m:2057
#1  0x000af6786cbc in release(objc_object*) () from 
/usr/local/lib/libobjc2.so.3.0
#2  0x000af6786b7c [PAC] in emptyPool(arc_tls*, void*) () from 
/usr/local/lib/libobjc2.so.3.0
#3  0x000af6786938 [PAC] in objc_autoreleasePoolPop () from 
/usr/local/lib/libobjc2.so.3.0
#4  0x000a975aa4fc [PAC] in -[NSAutoreleasePool dealloc] (self=0xabd627908, 
_cmd=0xa978b0778 ) at NSAutoreleasePool.m:571
#5  0x000601345908 [PAC] in gnustep_base_user_main (argc=, 
argv=, env=) at plmerge.m:139
#6  0x000601344eb8 [PAC] in _start ()


Index: games/oolite/Makefile
===
RCS file: /cvs/ports/games/oolite/Makefile,v
diff -u -p -r1.28 Makefile
--- games/oolite/Makefile   26 Sep 2023 09:41:39 -  1.28
+++ games/oolite/Makefile   8 Mar 2024 15:54:40 -
@@ -1,7 +1,7 @@
 COMMENT=   space combat and trading game in the style of Elite
 
 VERSION=   1.73.4
-REVISION = 18
+REVISION = 19
 DISTNAME=  oolite-dev-source-${VERSION}
 PKGNAME=   oolite-${VERSION}
 CATEGORIES=games
Index: www/sogo/Makefile
===
RCS file: /cvs/ports/www/sogo/Makefile,v
diff -u -p -r1.111 Makefile
--- www/sogo/Makefile   14 Jan 2024 20:49:18 -  1.111
+++ www/sogo/Makefile   8 Mar 2024 15:54:40 -
@@ -3,6 +3,7 @@ COMMENT =   web based groupware server
 VERSION =  5.9.1
 DISTNAME = SOGo-${VERSION}
 PKGNAME =  sogo-${VERSION}
+REVISION = 0
 
 SHARED_LIBS += GDLContentStore 3.0
 SHARED_LIBS += NGCards 3.1
Index: www/sope/Makefile
===
RCS file: /cvs/ports/www/sope/Makefile,v
diff -u -p -r1.99 Makefile
--- www/sope/Makefile   14 Jan 2024 20:40:45 -  1.99
+++ www/sope/Makefile   8 Mar 2024 15:54:40 -
@@ -7,6 +7,9 @@ DISTNAME =  SOPE-${VERSION}
 PKGNAME-main = sope-${VERSION}
 PKGNAME-mysql =sope-mysql-${VERSION}
 PKGNAME-postgres = sope-postgres-${VERSION}
+REVISION-main =0
+REVISION-mysql =   0
+REVISION-postgres =0
 
 SO_MAJOR=  6
 SO_MINOR=  0
Index: x11/gnustep/gnustep.port.mk
===
RCS file: /cvs/ports/x11/gnustep/gnustep.port.mk,v
diff -u -p -r1.41 gnustep.port.mk
--- x11/gnustep/gnustep.port.mk 27 Sep 2023 20:37:07 -  1.41
+++ x11/gnustep/gnustep.port.mk 8 Mar 2024 15:54:40 -
@@ -1,6 +1,18 @@
 # until tested on others
 ONLY_FOR_ARCHS ?=  ${LLD_ARCHS}
 
+USE_NOBTCFI-aarch64= Yes
+# Program terminated with signal SIGILL, Illegal instruction.
+# #0  -[NSBundle release] (self=0x14704af2d8, _cmd=) at 
NSBundle.m:2057
+# #1  0x001565473cbc in release(objc_object*) () from 
/usr/local/lib/libobjc2.so.3.0
+# #2  0x001565473ac8 [PAC] in emptyPool(arc_tls*, void*) () from 
/usr/local/lib/libobjc2.so.3.0
+# #3  0x001565473938 [PAC] in objc_autoreleasePoolPop () from 
/usr/local/lib/libobjc2.so.3.0
+# #4  0x001496a7553c [PAC] in -[NSAutoreleasePool dealloc] 
(self=0x15300e4788, _cmd=0x1496d7b7b8 ) at 
NSAutoreleasePool.m:571
+# #5  0x0014e4ff4f3c [PAC] in ?? () from 
/usr/local/lib/libgnustep-gui.so.0.32
+# #6  0x0014e4ff4414 [PAC] in ?? () from 
/usr/local/lib/libgnustep-gui.so.0.32
+

Re: gnustep/libobjc2 and BTI (was: Re: x11/gnustep/libobjc2 failed to build)

2024-03-07 Thread Mark Kettenis 
> Date: Thu, 7 Mar 2024 12:55:50 +
> From: Stuart Henderson 
> 
> On 2024/03/07 10:28, Mark Kettenis wrote:
> > This version looks best to me.  But I suspect arm64 needs more work in
> > this version too.
> 
> I tried to give it a spin with gnustep-based software, but no
> gnustep-base package is available for arm64 yet (I suspect because of
> the previous bugs in the libobjc2 port).
> 
> If I try to build gnustep-base myself it fails with BTI SIGILL during
> autoconf when doing a test for libffi, so it looks like we're probably
> missing something in libffi (tobhe fixed some things last November).
> I'm not getting useful backtraces so not sure where in libffi it's
> needed. Test program from libobjc2's autoconf files attached:
> 
> $ cc -I/usr/local/include -L/usr/local/lib config.ffi.c -lffi
> $ ktrace ./a.out
> a
> Illegal instruction (core dumped)
> $ kdump | tail
>   5909 a.outRET   mmap 29349658624/0x6d5604000
>   5909 a.outCALL  fcntl(1,F_ISATTY)
>   5909 a.outRET   fcntl 1
>   5909 a.outCALL  write(1,0x6d5604000,0x2)
>   5909 a.outGIO   fd 1 wrote 2 bytes
>"a
>"
>   5909 a.outRET   write 2
>   5909 a.outPSIG  SIGILL SIG_DFL code=ILL_BTCFI addr=0x6e74fe010 
> trapno=905969666
>   5909 a.outNAMI  "a.out.core"
> 
> "make test" in libffi runs ok, but picking another consumber of libffi
> I tried "make test" in guile3, and that has SIGILLs too.

I'll take a look.

Re: gnustep/libobjc2 and BTI (was: Re: x11/gnustep/libobjc2 failed to build)

2024-03-07 Thread Stuart Henderson 
On 2024/03/07 10:28, Mark Kettenis wrote:
> This version looks best to me.  But I suspect arm64 needs more work in
> this version too.

I tried to give it a spin with gnustep-based software, but no
gnustep-base package is available for arm64 yet (I suspect because of
the previous bugs in the libobjc2 port).

If I try to build gnustep-base myself it fails with BTI SIGILL during
autoconf when doing a test for libffi, so it looks like we're probably
missing something in libffi (tobhe fixed some things last November).
I'm not getting useful backtraces so not sure where in libffi it's
needed. Test program from libobjc2's autoconf files attached:

$ cc -I/usr/local/include -L/usr/local/lib config.ffi.c -lffi
$ ktrace ./a.out
a
Illegal instruction (core dumped)
$ kdump | tail
  5909 a.outRET   mmap 29349658624/0x6d5604000
  5909 a.outCALL  fcntl(1,F_ISATTY)
  5909 a.outRET   fcntl 1
  5909 a.outCALL  write(1,0x6d5604000,0x2)
  5909 a.outGIO   fd 1 wrote 2 bytes
   "a
   "
  5909 a.outRET   write 2
  5909 a.outPSIG  SIGILL SIG_DFL code=ILL_BTCFI addr=0x6e74fe010 
trapno=905969666
  5909 a.outNAMI  "a.out.core"

"make test" in libffi runs ok, but picking another consumber of libffi
I tried "make test" in guile3, and that has SIGILLs too.

#include 
#include 
#include 


typedef struct cls_struct_combined {
  float a;
  float b;
  float c;
  float d;
} cls_struct_combined;

void cls_struct_combined_fn(struct cls_struct_combined arg)
{
/*
  printf("GOT %g %g %g %g,  EXPECTED 4 5 1 8\n",
 arg.a, arg.b,
 arg.c, arg.d);
  fflush(stdout);
*/
  if (arg.a != 4 || arg.b != 5 || arg.c != 1 || arg.d != 8) abort();
}

static void
cls_struct_combined_gn(ffi_cif* cif, void* resp, void** args, void* userdata)
{
  struct cls_struct_combined a0;

  a0 = *(struct cls_struct_combined*)(args[0]);

  cls_struct_combined_fn(a0);
}


int main (void)
{
  ffi_cif cif;
  void *code;
  ffi_closure *pcl = ffi_closure_alloc(sizeof(ffi_closure), &code);
  ffi_type* cls_struct_fields0[5];
  ffi_type cls_struct_type0;
  ffi_type* dbl_arg_types[5];
  struct cls_struct_combined g_dbl = {4.0, 5.0, 1.0, 8.0};

  cls_struct_type0.size = 0;
  cls_struct_type0.alignment = 0;
  cls_struct_type0.type = FFI_TYPE_STRUCT;
  cls_struct_type0.elements = cls_struct_fields0;

  cls_struct_fields0[0] = &ffi_type_float;
  cls_struct_fields0[1] = &ffi_type_float;
  cls_struct_fields0[2] = &ffi_type_float;
  cls_struct_fields0[3] = &ffi_type_float;
  cls_struct_fields0[4] = NULL;

  dbl_arg_types[0] = &cls_struct_type0;
  dbl_arg_types[1] = NULL;

  if (ffi_prep_cif(&cif, FFI_DEFAULT_ABI, 1, &ffi_type_void, dbl_arg_types)
!= FFI_OK) abort();

  if (ffi_prep_closure_loc(pcl, &cif, cls_struct_combined_gn, NULL, code)
!= FFI_OK) abort();

  printf("a\n");
  ((void(*)(cls_struct_combined)) (code))(g_dbl);
  printf("b\n");
  exit(0);
}

Re: gnustep/libobjc2 and BTI (was: Re: x11/gnustep/libobjc2 failed to build)

2024-03-07 Thread Sebastian Reitenbach 
On Thursday, March 07, 2024 12:36 CET, Stuart Henderson  
wrote:

> > > > How do I get a BTI enabled machine?
> > 
> > Apparently most Intel Gen11+ CPUs have IBT.  For arm64 you need an
> > Apple M2.
> 
> Look for "Control-Flow Enforcement Technology" in the Intel cpu details
> page on ark.intel.com. Yes it needs to be gen11 or newer.
> 
> AMD does not have it yet.
> 
> Cheapest way is probably the N100-based mini PCs (not speed demons but
> fairly acceptable and they're really cheap).
> 
> For laptops, Thinkpad T14 are fairly common amongst developers.
> (T14 g2 has gen11 CPUs, all cores the same - T14 g3 has gen12, mix
> of performance + efficiency cores).
> 

I don't own such modern hardware ;)
But such N100 based mini PC looks like a viable option to add to my stack.

Sebastian

Re: gnustep/libobjc2 and BTI (was: Re: x11/gnustep/libobjc2 failed to build)

2024-03-07 Thread Sebastian Reitenbach 
On Thursday, March 07, 2024 10:28 CET, Mark Kettenis  
wrote:

> > From: "Sebastian Reitenbach" 
> > Date: Thu, 07 Mar 2024 09:01:13 +0100
> > 
> > Hi,
> > 
> > On Wednesday, March 06, 2024 23:42 CET, Mark Kettenis 
> >  wrote:
> > 
> > > > Date: Wed, 06 Mar 2024 23:32:51 +0100
> > > > From: Mark Kettenis 
> > > > 
> > > > > Date: Wed, 6 Mar 2024 19:02:35 +0100
> > > > > From: Jeremie Courreges-Anglas 
> > > > > 
> > > > > Le Wed, Mar 06, 2024 at 10:17:32AM +0100, Theo Buehler a écrit :
> > > > > > Could you please resend the endbr64 patches with Cc kettenis? They
> > > > > > should make release.
> > > > > 
> > > > > Since I now have a laptop with BTI I figured I was going to give this
> > > > > a try.  -current x11/gnustep/zipper was crashing with SIGILL on amd64.
> > > > > For the amd64 diff I'm deliberately not caring about the assembly for
> > > > > Windows.  I can't test the arm64 part but it looks simple.
> > > > > 
> > > > > ok?
> > > > > 
> > > > > Sebastian, feel free to commit this if it matches your previous diff.
> > > > 
> > > > Looks right to me.
> > > 
> > > Actually, the arm64 bit is probably incomplete.  And tb@ has a point
> > > that endbr64 should be after the .cfi_startproc.
> > > 
> > 
> > I already created a lot of mess rushing getting the update in, I'm 
> > a bit confused with this back and fourth. Before messing up even more, 
> > which of these should be the correct version, the one from tb@ or jca@ ?
> > And that one would also be complete in aarch64?
> > If I got all those threats right, the tb@ version would be the correct one?
> > Both attached below.
> > 
> > 
> > How do I get a BTI enabled machine?
> > 
> > Sebastian
> > 
> > tb@ version:
> 
> This version looks best to me.  But I suspect arm64 needs more work in
> this version too.
> 
> ok kettenis@
> 
Thank you all, this version is now in, I'll see to upstream it.

Sebastian

Re: gnustep/libobjc2 and BTI (was: Re: x11/gnustep/libobjc2 failed to build)

2024-03-07 Thread Stuart Henderson 
> > > How do I get a BTI enabled machine?
> 
> Apparently most Intel Gen11+ CPUs have IBT.  For arm64 you need an
> Apple M2.

Look for "Control-Flow Enforcement Technology" in the Intel cpu details
page on ark.intel.com. Yes it needs to be gen11 or newer.

AMD does not have it yet.

Cheapest way is probably the N100-based mini PCs (not speed demons but
fairly acceptable and they're really cheap).

For laptops, Thinkpad T14 are fairly common amongst developers.
(T14 g2 has gen11 CPUs, all cores the same - T14 g3 has gen12, mix
of performance + efficiency cores).

Re: gnustep/libobjc2 and BTI (was: Re: x11/gnustep/libobjc2 failed to build)

2024-03-07 Thread Jeremie Courreges-Anglas 
Le Thu, Mar 07, 2024 at 10:28:21AM +0100, Mark Kettenis a écrit :
> > From: "Sebastian Reitenbach" 
> > Date: Thu, 07 Mar 2024 09:01:13 +0100
> > 
> > Hi,
> > 
> > On Wednesday, March 06, 2024 23:42 CET, Mark Kettenis 
> >  wrote:
> > 
> > > > Date: Wed, 06 Mar 2024 23:32:51 +0100
> > > > From: Mark Kettenis 
> > > > 
> > > > > Date: Wed, 6 Mar 2024 19:02:35 +0100
> > > > > From: Jeremie Courreges-Anglas 
> > > > > 
> > > > > Le Wed, Mar 06, 2024 at 10:17:32AM +0100, Theo Buehler a écrit :
> > > > > > Could you please resend the endbr64 patches with Cc kettenis? They
> > > > > > should make release.
> > > > > 
> > > > > Since I now have a laptop with BTI I figured I was going to give this
> > > > > a try.  -current x11/gnustep/zipper was crashing with SIGILL on amd64.
> > > > > For the amd64 diff I'm deliberately not caring about the assembly for
> > > > > Windows.  I can't test the arm64 part but it looks simple.
> > > > > 
> > > > > ok?
> > > > > 
> > > > > Sebastian, feel free to commit this if it matches your previous diff.
> > > > 
> > > > Looks right to me.
> > > 
> > > Actually, the arm64 bit is probably incomplete.  And tb@ has a point
> > > that endbr64 should be after the .cfi_startproc.
> > > 
> > 
> > I already created a lot of mess rushing getting the update in, I'm 
> > a bit confused with this back and fourth. Before messing up even more, 
> > which of these should be the correct version, the one from tb@ or jca@ ?

Well I added to the confusion.  I did not have tb's diff at hand
yesterday, I cooked a subpar diff that fixed the crash and got trigger
happy.  That's a waste of time, sorry folks.

> > And that one would also be complete in aarch64?
> > If I got all those threats right, the tb@ version would be the correct one?
> > Both attached below.
> > 
> > 
> > How do I get a BTI enabled machine?

Apparently most Intel Gen11+ CPUs have IBT.  For arm64 you need an
Apple M2.

> > Sebastian
> > 
> > tb@ version:
> 
> This version looks best to me.

Agreed.

> But I suspect arm64 needs more work in
> this version too.
> 
> ok kettenis@

ok jca@

-- 
jca

Re: gnustep/libobjc2 and BTI (was: Re: x11/gnustep/libobjc2 failed to build)

2024-03-07 Thread Mark Kettenis 
> From: "Sebastian Reitenbach" 
> Date: Thu, 07 Mar 2024 09:01:13 +0100
> 
> Hi,
> 
> On Wednesday, March 06, 2024 23:42 CET, Mark Kettenis 
>  wrote:
> 
> > > Date: Wed, 06 Mar 2024 23:32:51 +0100
> > > From: Mark Kettenis 
> > > 
> > > > Date: Wed, 6 Mar 2024 19:02:35 +0100
> > > > From: Jeremie Courreges-Anglas 
> > > > 
> > > > Le Wed, Mar 06, 2024 at 10:17:32AM +0100, Theo Buehler a écrit :
> > > > > Could you please resend the endbr64 patches with Cc kettenis? They
> > > > > should make release.
> > > > 
> > > > Since I now have a laptop with BTI I figured I was going to give this
> > > > a try.  -current x11/gnustep/zipper was crashing with SIGILL on amd64.
> > > > For the amd64 diff I'm deliberately not caring about the assembly for
> > > > Windows.  I can't test the arm64 part but it looks simple.
> > > > 
> > > > ok?
> > > > 
> > > > Sebastian, feel free to commit this if it matches your previous diff.
> > > 
> > > Looks right to me.
> > 
> > Actually, the arm64 bit is probably incomplete.  And tb@ has a point
> > that endbr64 should be after the .cfi_startproc.
> > 
> 
> I already created a lot of mess rushing getting the update in, I'm 
> a bit confused with this back and fourth. Before messing up even more, 
> which of these should be the correct version, the one from tb@ or jca@ ?
> And that one would also be complete in aarch64?
> If I got all those threats right, the tb@ version would be the correct one?
> Both attached below.
> 
> 
> How do I get a BTI enabled machine?
> 
> Sebastian
> 
> tb@ version:

This version looks best to me.  But I suspect arm64 needs more work in
this version too.

ok kettenis@

> Index: patches/patch-block_trampolines_S
> ===
> RCS file: patches/patch-block_trampolines_S
> diff -N patches/patch-block_trampolines_S
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-block_trampolines_S 28 Feb 2024 20:08:24 -
> @@ -0,0 +1,19 @@
> +Index: block_trampolines.S
> +--- block_trampolines.S.orig
>  block_trampolines.S
> +@@ -22,6 +22,7 @@
> + // x86-64 trampoline
> + 
> 
> + .macro trampoline arg0, arg1
> ++endbr64
> + mov   -0x1007(%rip), \arg1   # Load the block pointer into the second 
> argument
> + xchg  \arg1, \arg0   # Swap the first and second arguments
> + jmp   *-0x1008(%rip) # Call the block function
> +@@ -121,6 +122,7 @@
> + // AArch64 (ARM64) trampoline
> + 
> 
> + .macro trampoline arg0, arg1
> ++bti c
> + adr x17, #-4096
> + mov \arg1, \arg0
> + ldp \arg0, x17, [x17]
> Index: patches/patch-objc_msgSend_aarch64_S
> ===
> RCS file: patches/patch-objc_msgSend_aarch64_S
> diff -N patches/patch-objc_msgSend_aarch64_S
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-objc_msgSend_aarch64_S  28 Feb 2024 20:08:24 -
> @@ -0,0 +1,12 @@
> +Index: objc_msgSend.aarch64.S
> +--- objc_msgSend.aarch64.S.orig
>  objc_msgSend.aarch64.S
> +@@ -47,7 +47,7 @@
> + #   define EH_NOP .seh_nop
> + #else
> + // Marks the real start and end of the function
> +-#   define EH_START .cfi_startproc
> ++#   define EH_START .cfi_startproc; bti c
> + #   define EH_END .cfi_endproc
> + 
> + // The following directives are either not
> Index: patches/patch-objc_msgSend_x86-64_S
> ===
> RCS file: patches/patch-objc_msgSend_x86-64_S
> diff -N patches/patch-objc_msgSend_x86-64_S
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-objc_msgSend_x86-64_S   28 Feb 2024 20:08:24 -
> @@ -0,0 +1,12 @@
> +Index: objc_msgSend.x86-64.S
> +--- objc_msgSend.x86-64.S.orig
>  objc_msgSend.x86-64.S
> +@@ -8,7 +8,7 @@
> + #   define SECOND_ARGUMENT %rdx
> + #   define THIRD_ARGUMENT %r8
> + #else
> +-#   define START_PROC(x) .cfi_startproc
> ++#   define START_PROC(x) .cfi_startproc; endbr64
> + #   define END_PROC(x) .cfi_endproc
> + #   define FRAME_OFFSET(x) .cfi_adjust_cfa_offset x
> + #   define FIRST_ARGUMENT_STR "%rdi"
> 
> 
> 
> @jca version:
> 
> 
> 
> Index: Makefile
> ===
> RCS file: /home/cvs/ports/x11/gnustep/libobjc2/Makefile,v
> diff -u -p -r1.37 Makefile
> --- Makefile  5 Mar 2024 16:11:15 -   1.37
> +++ Makefile  6 Mar 2024 17:26:11 -
> @@ -4,7 +4,7 @@ COMMENT = GNUstep libobjc2 objective-c r
>  
>  # note: this port does not use the gnustep module
>  VERSION =2.2
> -REVISION =   3
> +REVISION =   4
>  GH_ACCOUNT = gnustep
>  GH_PROJECT = libobjc2
>  GH_TAGNAME = v${VERSION}
> Index: patches/patch-objc_msgSend_aarch64_S
> ===
> RCS file: patches/patch-objc_msgSend_aarch64_S
> diff -N patches/p

Re: gnustep/libobjc2 and BTI (was: Re: x11/gnustep/libobjc2 failed to build)

2024-03-07 Thread Sebastian Reitenbach 
Hi,


On Wednesday, March 06, 2024 23:42 CET, Mark Kettenis  
wrote:

> > Date: Wed, 06 Mar 2024 23:32:51 +0100
> > From: Mark Kettenis 
> > 
> > > Date: Wed, 6 Mar 2024 19:02:35 +0100
> > > From: Jeremie Courreges-Anglas 
> > > 
> > > Le Wed, Mar 06, 2024 at 10:17:32AM +0100, Theo Buehler a écrit :
> > > > Could you please resend the endbr64 patches with Cc kettenis? They
> > > > should make release.
> > > 
> > > Since I now have a laptop with BTI I figured I was going to give this
> > > a try.  -current x11/gnustep/zipper was crashing with SIGILL on amd64.
> > > For the amd64 diff I'm deliberately not caring about the assembly for
> > > Windows.  I can't test the arm64 part but it looks simple.
> > > 
> > > ok?
> > > 
> > > Sebastian, feel free to commit this if it matches your previous diff.
> > 
> > Looks right to me.
> 
> Actually, the arm64 bit is probably incomplete.  And tb@ has a point
> that endbr64 should be after the .cfi_startproc.
> 

I already created a lot of mess rushing getting the update in, I'm 
a bit confused with this back and fourth. Before messing up even more, 
which of these should be the correct version, the one from tb@ or jca@ ?
And that one would also be complete in aarch64?
If I got all those threats right, the tb@ version would be the correct one?
Both attached below.


How do I get a BTI enabled machine?

Sebastian

tb@ version:

Index: patches/patch-block_trampolines_S
===
RCS file: patches/patch-block_trampolines_S
diff -N patches/patch-block_trampolines_S
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-block_trampolines_S   28 Feb 2024 20:08:24 -
@@ -0,0 +1,19 @@
+Index: block_trampolines.S
+--- block_trampolines.S.orig
 block_trampolines.S
+@@ -22,6 +22,7 @@
+ // x86-64 trampoline
+ 

+ .macro trampoline arg0, arg1
++  endbr64
+   mov   -0x1007(%rip), \arg1   # Load the block pointer into the second 
argument
+   xchg  \arg1, \arg0   # Swap the first and second arguments
+   jmp   *-0x1008(%rip) # Call the block function
+@@ -121,6 +122,7 @@
+ // AArch64 (ARM64) trampoline
+ 

+ .macro trampoline arg0, arg1
++  bti c
+   adr x17, #-4096
+   mov \arg1, \arg0
+   ldp \arg0, x17, [x17]
Index: patches/patch-objc_msgSend_aarch64_S
===
RCS file: patches/patch-objc_msgSend_aarch64_S
diff -N patches/patch-objc_msgSend_aarch64_S
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-objc_msgSend_aarch64_S28 Feb 2024 20:08:24 -
@@ -0,0 +1,12 @@
+Index: objc_msgSend.aarch64.S
+--- objc_msgSend.aarch64.S.orig
 objc_msgSend.aarch64.S
+@@ -47,7 +47,7 @@
+ #   define EH_NOP .seh_nop
+ #else
+ // Marks the real start and end of the function
+-#   define EH_START .cfi_startproc
++#   define EH_START .cfi_startproc; bti c
+ #   define EH_END .cfi_endproc
+ 
+ // The following directives are either not
Index: patches/patch-objc_msgSend_x86-64_S
===
RCS file: patches/patch-objc_msgSend_x86-64_S
diff -N patches/patch-objc_msgSend_x86-64_S
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-objc_msgSend_x86-64_S 28 Feb 2024 20:08:24 -
@@ -0,0 +1,12 @@
+Index: objc_msgSend.x86-64.S
+--- objc_msgSend.x86-64.S.orig
 objc_msgSend.x86-64.S
+@@ -8,7 +8,7 @@
+ # define SECOND_ARGUMENT %rdx
+ # define THIRD_ARGUMENT %r8
+ #else
+-# define START_PROC(x) .cfi_startproc
++# define START_PROC(x) .cfi_startproc; endbr64
+ # define END_PROC(x) .cfi_endproc
+ # define FRAME_OFFSET(x) .cfi_adjust_cfa_offset x
+ # define FIRST_ARGUMENT_STR "%rdi"



@jca version:



Index: Makefile
===
RCS file: /home/cvs/ports/x11/gnustep/libobjc2/Makefile,v
diff -u -p -r1.37 Makefile
--- Makefile5 Mar 2024 16:11:15 -   1.37
+++ Makefile6 Mar 2024 17:26:11 -
@@ -4,7 +4,7 @@ COMMENT =   GNUstep libobjc2 objective-c r
 
 # note: this port does not use the gnustep module
 VERSION =  2.2
-REVISION = 3
+REVISION = 4
 GH_ACCOUNT =   gnustep
 GH_PROJECT =   libobjc2
 GH_TAGNAME =   v${VERSION}
Index: patches/patch-objc_msgSend_aarch64_S
===
RCS file: patches/patch-objc_msgSend_aarch64_S
diff -N patches/patch-objc_msgSend_aarch64_S
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-objc_msgSend_aarch64_S6 Mar 2024 17:19:04 -
@@ -0,0 +1,11 @@
+Index: objc_msgSend.aarch64.S
+--- objc_msgSend.aarch64.S.orig
 objc_msgSend.aarch64.S
+@@ -73,6 +73,7 @@ CDECL(objc_msgSend):
+ CDECL(objc_msgSend_fpret):
+ CDECL(objc_msgSend_stret):
+   EH_START
++  btic
+ 
+   cb

Re: gnustep/libobjc2 and BTI (was: Re: x11/gnustep/libobjc2 failed to build)

2024-03-06 Thread Mark Kettenis 
> Date: Wed, 06 Mar 2024 23:32:51 +0100
> From: Mark Kettenis 
> 
> > Date: Wed, 6 Mar 2024 19:02:35 +0100
> > From: Jeremie Courreges-Anglas 
> > 
> > Le Wed, Mar 06, 2024 at 10:17:32AM +0100, Theo Buehler a écrit :
> > > Could you please resend the endbr64 patches with Cc kettenis? They
> > > should make release.
> > 
> > Since I now have a laptop with BTI I figured I was going to give this
> > a try.  -current x11/gnustep/zipper was crashing with SIGILL on amd64.
> > For the amd64 diff I'm deliberately not caring about the assembly for
> > Windows.  I can't test the arm64 part but it looks simple.
> > 
> > ok?
> > 
> > Sebastian, feel free to commit this if it matches your previous diff.
> 
> Looks right to me.

Actually, the arm64 bit is probably incomplete.  And tb@ has a point
that endbr64 should be after the .cfi_startproc.

> > Index: Makefile
> > ===
> > RCS file: /home/cvs/ports/x11/gnustep/libobjc2/Makefile,v
> > diff -u -p -r1.37 Makefile
> > --- Makefile5 Mar 2024 16:11:15 -   1.37
> > +++ Makefile6 Mar 2024 17:26:11 -
> > @@ -4,7 +4,7 @@ COMMENT =   GNUstep libobjc2 objective-c r
> >  
> >  # note: this port does not use the gnustep module
> >  VERSION =  2.2
> > -REVISION = 3
> > +REVISION = 4
> >  GH_ACCOUNT =   gnustep
> >  GH_PROJECT =   libobjc2
> >  GH_TAGNAME =   v${VERSION}
> > Index: patches/patch-objc_msgSend_aarch64_S
> > ===
> > RCS file: patches/patch-objc_msgSend_aarch64_S
> > diff -N patches/patch-objc_msgSend_aarch64_S
> > --- /dev/null   1 Jan 1970 00:00:00 -
> > +++ patches/patch-objc_msgSend_aarch64_S6 Mar 2024 17:19:04 -
> > @@ -0,0 +1,11 @@
> > +Index: objc_msgSend.aarch64.S
> > +--- objc_msgSend.aarch64.S.orig
> >  objc_msgSend.aarch64.S
> > +@@ -73,6 +73,7 @@ CDECL(objc_msgSend):
> > + CDECL(objc_msgSend_fpret):
> > + CDECL(objc_msgSend_stret):
> > +   EH_START
> > ++  btic
> > + 
> > +   cbzx0, 4f   // Skip everything if the receiver is 
> > nil
> > +  // Jump to 6: if this is a small 
> > object
> > Index: patches/patch-objc_msgSend_x86-64_S
> > ===
> > RCS file: patches/patch-objc_msgSend_x86-64_S
> > diff -N patches/patch-objc_msgSend_x86-64_S
> > --- /dev/null   1 Jan 1970 00:00:00 -
> > +++ patches/patch-objc_msgSend_x86-64_S 6 Mar 2024 17:18:56 -
> > @@ -0,0 +1,15 @@
> > +Index: objc_msgSend.x86-64.S
> > +--- objc_msgSend.x86-64.S.orig
> >  objc_msgSend.x86-64.S
> > +@@ -307,9 +307,11 @@ TYPE_DIRECTIVE(CDECL(objc_msgSend), @function)
> > + TYPE_DIRECTIVE(CDECL(objc_msgSend_fpret), @function)
> > + CDECL(objc_msgSend_fpret):
> > + CDECL(objc_msgSend):
> > ++  endbr64
> > +   MSGSEND objc_msgSend, %rdi, %rsi
> > + .globl CDECL(objc_msgSend_stret)
> > + TYPE_DIRECTIVE(CDECL(objc_msgSend_stret), @function)
> > + CDECL(objc_msgSend_stret):
> > ++  endbr64
> > +   MSGSEND objc_msgSend_stret, %rsi, %rdx
> > + #endif
> > 
> > 
> > -- 
> > jca
> > 
>

Re: gnustep/libobjc2 and BTI (was: Re: x11/gnustep/libobjc2 failed to build)

2024-03-06 Thread Mark Kettenis 
> Date: Wed, 6 Mar 2024 19:02:35 +0100
> From: Jeremie Courreges-Anglas 
> 
> Le Wed, Mar 06, 2024 at 10:17:32AM +0100, Theo Buehler a écrit :
> > Could you please resend the endbr64 patches with Cc kettenis? They
> > should make release.
> 
> Since I now have a laptop with BTI I figured I was going to give this
> a try.  -current x11/gnustep/zipper was crashing with SIGILL on amd64.
> For the amd64 diff I'm deliberately not caring about the assembly for
> Windows.  I can't test the arm64 part but it looks simple.
> 
> ok?
> 
> Sebastian, feel free to commit this if it matches your previous diff.

Looks right to me.

> Index: Makefile
> ===
> RCS file: /home/cvs/ports/x11/gnustep/libobjc2/Makefile,v
> diff -u -p -r1.37 Makefile
> --- Makefile  5 Mar 2024 16:11:15 -   1.37
> +++ Makefile  6 Mar 2024 17:26:11 -
> @@ -4,7 +4,7 @@ COMMENT = GNUstep libobjc2 objective-c r
>  
>  # note: this port does not use the gnustep module
>  VERSION =2.2
> -REVISION =   3
> +REVISION =   4
>  GH_ACCOUNT = gnustep
>  GH_PROJECT = libobjc2
>  GH_TAGNAME = v${VERSION}
> Index: patches/patch-objc_msgSend_aarch64_S
> ===
> RCS file: patches/patch-objc_msgSend_aarch64_S
> diff -N patches/patch-objc_msgSend_aarch64_S
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-objc_msgSend_aarch64_S  6 Mar 2024 17:19:04 -
> @@ -0,0 +1,11 @@
> +Index: objc_msgSend.aarch64.S
> +--- objc_msgSend.aarch64.S.orig
>  objc_msgSend.aarch64.S
> +@@ -73,6 +73,7 @@ CDECL(objc_msgSend):
> + CDECL(objc_msgSend_fpret):
> + CDECL(objc_msgSend_stret):
> + EH_START
> ++btic
> + 
> + cbzx0, 4f   // Skip everything if the receiver is 
> nil
> +// Jump to 6: if this is a small 
> object
> Index: patches/patch-objc_msgSend_x86-64_S
> ===
> RCS file: patches/patch-objc_msgSend_x86-64_S
> diff -N patches/patch-objc_msgSend_x86-64_S
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-objc_msgSend_x86-64_S   6 Mar 2024 17:18:56 -
> @@ -0,0 +1,15 @@
> +Index: objc_msgSend.x86-64.S
> +--- objc_msgSend.x86-64.S.orig
>  objc_msgSend.x86-64.S
> +@@ -307,9 +307,11 @@ TYPE_DIRECTIVE(CDECL(objc_msgSend), @function)
> + TYPE_DIRECTIVE(CDECL(objc_msgSend_fpret), @function)
> + CDECL(objc_msgSend_fpret):
> + CDECL(objc_msgSend):
> ++endbr64
> + MSGSEND objc_msgSend, %rdi, %rsi
> + .globl CDECL(objc_msgSend_stret)
> + TYPE_DIRECTIVE(CDECL(objc_msgSend_stret), @function)
> + CDECL(objc_msgSend_stret):
> ++endbr64
> + MSGSEND objc_msgSend_stret, %rsi, %rdx
> + #endif
> 
> 
> -- 
> jca
>

Re: gnustep/libobjc2 and BTI (was: Re: x11/gnustep/libobjc2 failed to build)

2024-03-06 Thread Theo Buehler 
On Wed, Mar 06, 2024 at 07:02:35PM +0100, Jeremie Courreges-Anglas wrote:
> Le Wed, Mar 06, 2024 at 10:17:32AM +0100, Theo Buehler a écrit :
> > Could you please resend the endbr64 patches with Cc kettenis? They
> > should make release.
> 
> Since I now have a laptop with BTI I figured I was going to give this
> a try.  -current x11/gnustep/zipper was crashing with SIGILL on amd64.
> For the amd64 diff I'm deliberately not caring about the assembly for
> Windows.  I can't test the arm64 part but it looks simple.
> 
> ok?

I had a somewhat different approach:
https://marc.info/?l=openbsd-ports&m=170915116023144&w=2

Since you add the endbr64 before the MSGSEND macro, they now come before
.cfi_startproc. In all other patches I'm aware of, we put them after.
Not sure if that will matter in the future.

I also added landing pads to the trampolines; I'm sure the old libobjc2
warned about these with kettenis's ld.lld diff. Maybe it's no longer
needed.

> 
> Sebastian, feel free to commit this if it matches your previous diff.
> 
> 
> Index: Makefile
> ===
> RCS file: /home/cvs/ports/x11/gnustep/libobjc2/Makefile,v
> diff -u -p -r1.37 Makefile
> --- Makefile  5 Mar 2024 16:11:15 -   1.37
> +++ Makefile  6 Mar 2024 17:26:11 -
> @@ -4,7 +4,7 @@ COMMENT = GNUstep libobjc2 objective-c r
>  
>  # note: this port does not use the gnustep module
>  VERSION =2.2
> -REVISION =   3
> +REVISION =   4
>  GH_ACCOUNT = gnustep
>  GH_PROJECT = libobjc2
>  GH_TAGNAME = v${VERSION}
> Index: patches/patch-objc_msgSend_aarch64_S
> ===
> RCS file: patches/patch-objc_msgSend_aarch64_S
> diff -N patches/patch-objc_msgSend_aarch64_S
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-objc_msgSend_aarch64_S  6 Mar 2024 17:19:04 -
> @@ -0,0 +1,11 @@
> +Index: objc_msgSend.aarch64.S
> +--- objc_msgSend.aarch64.S.orig
>  objc_msgSend.aarch64.S
> +@@ -73,6 +73,7 @@ CDECL(objc_msgSend):
> + CDECL(objc_msgSend_fpret):
> + CDECL(objc_msgSend_stret):
> + EH_START
> ++btic
> + 
> + cbzx0, 4f   // Skip everything if the receiver is 
> nil
> +// Jump to 6: if this is a small 
> object
> Index: patches/patch-objc_msgSend_x86-64_S
> ===
> RCS file: patches/patch-objc_msgSend_x86-64_S
> diff -N patches/patch-objc_msgSend_x86-64_S
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-objc_msgSend_x86-64_S   6 Mar 2024 17:18:56 -
> @@ -0,0 +1,15 @@
> +Index: objc_msgSend.x86-64.S
> +--- objc_msgSend.x86-64.S.orig
>  objc_msgSend.x86-64.S
> +@@ -307,9 +307,11 @@ TYPE_DIRECTIVE(CDECL(objc_msgSend), @function)
> + TYPE_DIRECTIVE(CDECL(objc_msgSend_fpret), @function)
> + CDECL(objc_msgSend_fpret):
> + CDECL(objc_msgSend):
> ++endbr64
> + MSGSEND objc_msgSend, %rdi, %rsi
> + .globl CDECL(objc_msgSend_stret)
> + TYPE_DIRECTIVE(CDECL(objc_msgSend_stret), @function)
> + CDECL(objc_msgSend_stret):
> ++endbr64
> + MSGSEND objc_msgSend_stret, %rsi, %rdx
> + #endif
> 
> 
> -- 
> jca
>