Re: crunchgen and llvm 15
> I'm not sure which way to go: either sprinkle some -fno-common between > crunchgen and distrib/special/Makefile.inc, or drop -dc on lld archs > only. What would you folks prefer? I'd rather have the same behaviour for all platforms, but I need to test a few more gcc platforms first.
Re: crunchgen and llvm 15
On Fri, Dec 30 2022, Miod Vallat wrote:
> You need this extra chunk for your diff to work. With that, the built
> instbin binary appears to behave as expected on hppa.
Heh, nice, thank you.
I'm not sure which way to go: either sprinkle some -fno-common between
crunchgen and distrib/special/Makefile.inc, or drop -dc on lld archs
only. What would you folks prefer?
commit 548e9fc8c0cf82bccbd91ce2d0b7af7ae12a3207
Author: jca
Date: Fri Dec 30 08:01:56 2022 +0100
crunchgen: stop using ld -dc on lld archs (dropped in lld 15)
diff --git a/usr.sbin/crunchgen/crunchgen.c b/usr.sbin/crunchgen/crunchgen.c
index 4526290197e..7136c1d19c9 100644
--- a/usr.sbin/crunchgen/crunchgen.c
+++ b/usr.sbin/crunchgen/crunchgen.c
@@ -898,7 +898,11 @@ top_makefile_rules(FILE * outmk)
fprintf(outmk, "CFLAGS+=-fno-asynchronous-unwind-tables\n");
fprintf(outmk, "LDFLAGS+=$(NOPIE_LDFLAGS)\n");
fprintf(outmk, "STRIP?=strip\n");
+ fprintf(outmk, ".if ${LINKER_VERSION} == \"lld\"\n");
+ fprintf(outmk, "LINK=$(LD) -r ${LDFLAGS}\n");
+ fprintf(outmk, ".else\n");
fprintf(outmk, "LINK=$(LD) -dc -r ${LDFLAGS}\n");
+ fprintf(outmk, ".endif\n");
fprintf(outmk, "LIBS=");
for (l = libdirs; l != NULL; l = l->next)
fprintf(outmk, " -L%s", l->str);
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: clang 15 and zlib
On Wed, Dec 28 2022, Jeremie Courreges-Anglas wrote: > To build src cleanly with clang-15 you'd need the diff below. The > alternative would be to patch our three zlib copies and wait for > upstream to fix it. A more comfortable alternative is to just neuter > the warning. -Wno-unknown-warning-option prevents llvm 13 from > complaining that it doesn't know about -Wno-deprecated-non-prototype and > should ease the transition. I took care to only add this workaround on > clang archs, Committed, thanks. > and to respect the COMPILER_VERSION checks where due. I had missed the COMPILER_VERSION check in sys/arch/amd64/stand/Makefile.inc and sys/arch/i386/stand/Makefile.inc, now fixed. You'll have to clean up your tree. -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: crunchgen and llvm 15
You need this extra chunk for your diff to work. With that, the built instbin binary appears to behave as expected on hppa. Index: distrib/special/Makefile.inc === RCS file: /OpenBSD/src/distrib/special/Makefile.inc,v retrieving revision 1.9 diff -u -p -u -p -r1.9 Makefile.inc --- distrib/special/Makefile.inc10 Mar 2021 22:52:28 - 1.9 +++ distrib/special/Makefile.inc30 Dec 2022 06:14:37 - @@ -1,7 +1,7 @@ # options for all the directories below COPTS+=-Oz -fno-stack-protector -COPTS+=-fno-unwind-tables -fno-asynchronous-unwind-tables +COPTS+=-fno-unwind-tables -fno-asynchronous-unwind-tables -fno-common MAN= LDSTATIC=-static NOPIE=
Re: libcbor v0.10.0
On Fri, Dec 30, 2022 at 12:41:59PM +1100, Damien Miller wrote: > On Fri, 30 Dec 2022, Theo Buehler wrote: > > > On Fri, Dec 30, 2022 at 10:09:16AM +1100, Damien Miller wrote: > > > This updates libcbor to upstream version v.0.10.0. This version includes > > > clang15 header fixes and fixes a few memory leaks. Full release notes > > > are at https://github.com/PJK/libcbor/releases/tag/v0.10.0 > > > > I understand that it is a libcbor major bump. Why is the libfido2 bump > > needed? > > Caution - some of the libcbor changes were listed as "breaking" in the > release notes. I took this to mean an ABI bump. libfido2 depends on > libcbor, so I figured that bumping it would avoid any possibility of > inconsistency between them at link time. Too much? There are numerous ABI breaks in libcbor that do require a major bump: size_t -> uint64_t in public API, enum values added and removed, ... It's thus perfectly reasonable to bump libfido2. I was just wondering whether there was a more specific reason since I couldn't immediately spot anything. This bump is cheap, by all means keep it. > > The CBOR_CUSTOM_ALLOC deprecation and the fact that cbor_set_allocs() is > > now exposed is a bit disappointing. > > > > https://github.com/PJK/libcbor/pull/237 > > > > Other than that the diff looks good to me, build tested on sparc64, so > > gcc-archs should be fine, too. > > That's reasonable. I can chop those out: Yes, I think that makes sense and isn't super intrusive. I'd prefer this version. (It's a bit strange to write "Will keep this PR open for a few weeks to give people a chance to object." and then turn around, merge it and cut a release containing it.)
Re: libcbor v0.10.0
On Fri, 30 Dec 2022, Theo Buehler wrote:
> On Fri, Dec 30, 2022 at 10:09:16AM +1100, Damien Miller wrote:
> > This updates libcbor to upstream version v.0.10.0. This version includes
> > clang15 header fixes and fixes a few memory leaks. Full release notes
> > are at https://github.com/PJK/libcbor/releases/tag/v0.10.0
>
> I understand that it is a libcbor major bump. Why is the libfido2 bump
> needed?
Caution - some of the libcbor changes were listed as "breaking" in the
release notes. I took this to mean an ABI bump. libfido2 depends on
libcbor, so I figured that bumping it would avoid any possibility of
inconsistency between them at link time. Too much?
> The CBOR_CUSTOM_ALLOC deprecation and the fact that cbor_set_allocs() is
> now exposed is a bit disappointing.
>
> https://github.com/PJK/libcbor/pull/237
>
> Other than that the diff looks good to me, build tested on sparc64, so
> gcc-archs should be fine, too.
That's reasonable. I can chop those out:
Index: Makefile
===
RCS file: /cvs/src/lib/libcbor/Makefile,v
retrieving revision 1.3
diff -u -p -r1.3 Makefile
--- Makefile3 Aug 2020 02:34:31 - 1.3
+++ Makefile30 Dec 2022 01:37:31 -
@@ -3,6 +3,8 @@
.PATH: ${.CURDIR}/src ${.CURDIR}/src/cbor ${.CURDIR}/src/cbor/internal
CFLAGS+= -I${.CURDIR}/src -DHAVE_ENDIAN_H -std=c99
+# We don't support custom allocators.
+CFLAGS+= -D_cbor_malloc=malloc -D_cbor_realloc=realloc -D_cbor_free=free
LIB= cbor
SRCS= cbor.c
cbor/common.h now looks like this:
+#if 0 /* custom allocators are not supported on OpenBSD */
+typedef void *(*_cbor_malloc_t)(size_t);
+typedef void *(*_cbor_realloc_t)(void *, size_t);
+typedef void (*_cbor_free_t)(void *);
+
+CBOR_EXPORT extern _cbor_malloc_t _cbor_malloc;
+CBOR_EXPORT extern _cbor_realloc_t _cbor_realloc;
+CBOR_EXPORT extern _cbor_free_t _cbor_free;
+#endif
...
+#if 0 /* not on OpenBSD */
+CBOR_EXPORT void cbor_set_allocs(_cbor_malloc_t custom_malloc,
+ _cbor_realloc_t custom_realloc,
+ _cbor_free_t custom_free);
#endif
Re: libcbor v0.10.0
On Fri, Dec 30, 2022 at 10:09:16AM +1100, Damien Miller wrote: > This updates libcbor to upstream version v.0.10.0. This version includes > clang15 header fixes and fixes a few memory leaks. Full release notes > are at https://github.com/PJK/libcbor/releases/tag/v0.10.0 I understand that it is a libcbor major bump. Why is the libfido2 bump needed? The CBOR_CUSTOM_ALLOC deprecation and the fact that cbor_set_allocs() is now exposed is a bit disappointing. https://github.com/PJK/libcbor/pull/237 Other than that the diff looks good to me, build tested on sparc64, so gcc-archs should be fine, too. ok tb
Re: units(1): support personal library
On 2022/12/24 11:56:37 +0100, Florian Obser wrote:
> This is at least supported by FreeBSD's units(1) as well as by
> systemd/Linux.
>
> [...]
>
> OK?
it's really handy, ok for me! (with s/options/option as mentioned by
Crystal Kolipe.)
the -f '' seems a bit weird to be fair, but it's also possible to do
-f /usr/share/misc/units.lib now at least :)
> diff --git units.1 units.1
> index d7a45f729b3..916d1b03d32 100644
> --- units.1
> +++ units.1
> @@ -79,6 +79,11 @@ The options are as follows:
> .Bl -tag -width Ds
> .It Fl f Ar filename
> Specifies the name of the units data file to load.
> +This options may be specified multiple times.
> +The standard units library is read if
> +.Ar filename
> +is the empty string.
> +This allows extending the standard units library with a personal library.
> .It Fl q
> Suppresses prompting of the user for units and the display of statistics
> about the number of units loaded.
> diff --git units.c units.c
> index 98af5031fb1..488795c78cb 100644
> --- units.c
> +++ units.c
> @@ -100,7 +100,6 @@ readunits(char *userfile)
> int len, linenum, i;
> FILE *unitfile;
>
> - unitcount = 0;
> linenum = 0;
>
> if (userfile) {
> @@ -626,8 +625,7 @@ main(int argc, char **argv)
> struct unittype have, want;
> char havestr[81], wantstr[81];
> int optchar;
> - char *userfile = 0;
> - int quiet = 0;
> + int quiet = 0, units_read = 0;
>
> extern char *optarg;
> extern int optind;
> @@ -638,7 +636,8 @@ main(int argc, char **argv)
> while ((optchar = getopt(argc, argv, "vqf:")) != -1) {
> switch (optchar) {
> case 'f':
> - userfile = optarg;
> + units_read = 1;
> + readunits(*optarg == '\0' ? NULL : optarg);
> break;
> case 'q':
> quiet = 1;
> @@ -662,7 +661,8 @@ main(int argc, char **argv)
> if (argc != 3 && argc != 2 && argc != 0)
> usage();
>
> - readunits(userfile);
> + if (!units_read)
> + readunits(NULL);
>
> if (pledge("stdio", NULL) == -1)
> err(1, "pledge");
Re: crunchgen and llvm 15
> IIUC this ld(1) behavior is somewhat similar to -fno-common for cc(1). > base-clang already does -fno-common by default, base-gcc does not. The > diff below replaces ld -dc by cc -fno-common, but TBF I'm not sure what > we're trying to achieve (avoid?) here. A test (make build + release) on > a base-gcc arch would be welcome. An hppa snap with this diff builds without problems, but the resulting binary in bsd.rd does not run correctly: ... root on rd0a swap on rd0b dump on rd0b panic: init died (signal 0, exit 11) I will investigate further.
Re: define arm system register names
On Thu, Dec 29, 2022 at 02:38:18PM +0100, Janne Johansson wrote: > > +#defineSCTLR_EOE 0x0100 /* endianness of > > explcit data */ > > Misspelled "explicit" there. > > -- > May the most significant bit of your life be positive. Some had to be cut short in order to stay on a 80 character line, for neatness. It's not some help call attempt in steganography or anything *laugh*. Feel free to take it or leave it. Best Regards, -peter
Re: define arm system register names
> +#defineSCTLR_EOE 0x0100 /* endianness of > explcit data */ Misspelled "explicit" there. -- May the most significant bit of your life be positive.
define arm system register names
from: https://developer.arm.com/documentation/den0024/a/ARMv8-Registers/System-registers/The-system-control-register?lang=en The following patch tries to describe the system register in the source code to the best of my ability. Source comment change only, no binary change. Excuse that this is against a patched 7.2 system, please. If you would like to ask me a question regarding this patch reply to me directly as I'm not on the tech@ list. -peter Index: armreg.h === RCS file: /cvs/src/sys/arch/arm64/include/armreg.h,v retrieving revision 1.21 diff -u -p -u -r1.21 armreg.h --- armreg.h29 Aug 2022 02:01:18 - 1.21 +++ armreg.h29 Dec 2022 12:48:23 - @@ -560,26 +560,26 @@ #defineSCTLR_RES0 0xc8222400 /* Reserved, write 0 */ #defineSCTLR_RES1 0x30d00800 /* Reserved, write 1 */ -#defineSCTLR_M 0x0001 -#defineSCTLR_A 0x0002 -#defineSCTLR_C 0x0004 -#defineSCTLR_SA0x0008 -#defineSCTLR_SA0 0x0010 -#defineSCTLR_CP15BEN 0x0020 -#defineSCTLR_THEE 0x0040 -#defineSCTLR_ITD 0x0080 -#defineSCTLR_SED 0x0100 -#defineSCTLR_UMA 0x0200 -#defineSCTLR_I 0x1000 -#defineSCTLR_DZE 0x4000 -#defineSCTLR_UCT 0x8000 -#defineSCTLR_nTWI 0x0001 -#defineSCTLR_nTWE 0x0004 -#defineSCTLR_WXN 0x0008 -#defineSCTLR_SPAN 0x0080 -#defineSCTLR_EOE 0x0100 -#defineSCTLR_EE0x0200 -#defineSCTLR_UCI 0x0400 +#defineSCTLR_M 0x0001 /* enable MMU */ +#defineSCTLR_A 0x0002 /* alignment check enable bit */ +#defineSCTLR_C 0x0004 /* data cache enable */ +#defineSCTLR_SA0x0008 /* stack alignment check enbl */ +#defineSCTLR_SA0 0x0010 /* stack align check for sa0 */ +#defineSCTLR_CP15BEN 0x0020 /* CP15 barrier enable */ +#defineSCTLR_THEE 0x0040 +#defineSCTLR_ITD 0x0080 /* IT disable */ +#defineSCTLR_SED 0x0100 /* SET END disable */ +#defineSCTLR_UMA 0x0200 /* User Mask access */ +#defineSCTLR_I 0x1000 /* Instruction cache enable */ +#defineSCTLR_DZE 0x4000 /* access to DC ZVA Instr. */ +#defineSCTLR_UCT 0x8000 /* Enable El0 access */ +#defineSCTLR_nTWI 0x0001 /* Not trap WFI */ +#defineSCTLR_nTWE 0x0004 /* Not trap WFE */ +#defineSCTLR_WXN 0x0008 /* write perm implies XN */ +#defineSCTLR_SPAN 0x0080 +#defineSCTLR_EOE 0x0100 /* endianness of explcit data */ +#defineSCTLR_EE0x0200 /* exception endianness */ +#defineSCTLR_UCI 0x0400 /* enable 64-bit ELO access */ /* SPSR_EL1 */ /*
Re: Supprt FTDI FT232R
On Thu, Dec 29, 2022 at 03:05:35PM +0800, Kevin Lo wrote:
> The diff below makes the serial interface of the Genio 1200 demo board
> (FT232R)
> work. The upper 2 bits encode the fractional component of the FT232R is
> either
> 0 or 0.125.
>
> uftdi0 at uhub0 port 3 configuration 1 interface 0 "FTDI FT232R USB UART" rev
> 2.00/6.00 addr 2
> ucom0 at uftdi0 portno 1
>
> Tested with cu.
>
> ok?
looks nice and simple to me. ok.
>
> Index: sys/dev/usb/uftdi.c
> ===
> RCS file: /cvs/src/sys/dev/usb/uftdi.c,v
> retrieving revision 1.77
> diff -u -p -u -p -r1.77 uftdi.c
> --- sys/dev/usb/uftdi.c 9 Apr 2022 20:07:44 - 1.77
> +++ sys/dev/usb/uftdi.c 29 Dec 2022 06:40:32 -
> @@ -97,7 +97,7 @@ voiduftdi_read(void *sc, int portno, u_
> void uftdi_write(void *sc, int portno, u_char *to, u_char *from,
> u_int32_t *count);
> void uftdi_break(void *sc, int portno, int onoff);
> -int uftdi_8u232am_getrate(speed_t speed, int *rate);
> +int uftdi_8u232am_getrate(struct uftdi_softc *sc, speed_t speed, int *rate);
> int uftdi_2232h_getrate(speed_t speed, int *rate);
>
> const struct ucom_methods uftdi_methods = {
> @@ -772,6 +772,9 @@ uftdi_attach(struct device *parent, stru
> if (uaa->release < 0x0200) {
> sc->sc_type = UFTDI_TYPE_SIO;
> sc->sc_hdrlen = 1;
> + } else if (uaa->release == 0x0600) {
> + sc->sc_type = UFTDI_TYPE_232R;
> + sc->sc_hdrlen = 0;
> } else if (uaa->release == 0x0700 || uaa->release == 0x0800) {
> sc->sc_type = UFTDI_TYPE_2232H;
> sc->sc_hdrlen = 0;
> @@ -1011,8 +1014,9 @@ uftdi_param(void *vsc, int portno, struc
> }
> break;
>
> + case UFTDI_TYPE_232R:
> case UFTDI_TYPE_8U232AM:
> - if (uftdi_8u232am_getrate(t->c_ospeed, ) == -1)
> + if (uftdi_8u232am_getrate(sc, t->c_ospeed, ) == -1)
> return (EINVAL);
> break;
> case UFTDI_TYPE_2232H:
> @@ -1131,7 +1135,7 @@ uftdi_break(void *vsc, int portno, int o
> }
>
> int
> -uftdi_8u232am_getrate(speed_t speed, int *rate)
> +uftdi_8u232am_getrate(struct uftdi_softc *sc, speed_t speed, int *rate)
> {
> /* Table of the nearest even powers-of-2 for values 0..15. */
> static const unsigned char roundoff[16] = {
> @@ -1182,11 +1186,13 @@ uftdi_8u232am_getrate(speed_t speed, int
>* 0.125.
>*/
> result = d >> 4;
> - if (d & 8)
> - result |= 0x4000;
> - else if (d & 4)
> - result |= 0x8000;
> - else if (d & 2)
> + if (sc->sc_type == UFTDI_TYPE_8U232AM) {
> + if (d & 8)
> + result |= 0x4000;
> + else if (d & 4)
> + result |= 0x8000;
> + }
> + if (d & 2)
> result |= 0xc000;
>
> done:
> Index: sys/dev/usb/uftdireg.h
> ===
> RCS file: /cvs/src/sys/dev/usb/uftdireg.h,v
> retrieving revision 1.13
> diff -u -p -u -p -r1.13 uftdireg.h
> --- sys/dev/usb/uftdireg.h11 Sep 2012 16:04:44 - 1.13
> +++ sys/dev/usb/uftdireg.h29 Dec 2022 06:40:32 -
> @@ -36,7 +36,8 @@
> enum uftdi_type {
> UFTDI_TYPE_SIO,
> UFTDI_TYPE_8U232AM,
> - UFTDI_TYPE_2232H
> + UFTDI_TYPE_2232H,
> + UFTDI_TYPE_232R
> };
>
> /*
>
Re: [patch] arp.c spaces nested between tabs
On 2022/12/28 12:21:07 -0500, Paul Tagliamonte wrote:
> [2]: {openbsd monks avert your eyes: gnu grep and bash w/ 'shopt -s extglob'}:
> $ grep -P '\t +\t' !(gnu|sys) -ril
ksh actually supports that style of globbing :)
% ls -d !(gnu|sys)
Makefiledistrib/include/regress/usr.bin/
Makefile.cross etc/lib/sbin/ usr.sbin/
bin/games/ libexec/share/
