In D41745#983815, @markj wrote:

If I compile usr.sbin/dtrace with this patch applied, I get:

In file included from /home/markj/src/freebsd/cddl/contrib/opensolaris/cmd/dtrace/dtrace.c:59:
/usr/include/libxo/xo.h:31:9: error: 'NORETURN' macro redefined [-Werror,-Wmacro-redefined]
   31 | #define NORETURN __dead2
      |         ^
/home/markj/src/freebsd/sys/contrib/openzfs/lib/libspl/include/assert.h:44:9: note: previous definition is here
   44 | #define NORETURN        __attribute__((__noreturn__))
      |         ^
1 error generated.
*** Error code 1

Stop.
make: stopped in /home/markj/src/freebsd/cddl/usr.sbin/dtrace

I tend to think that xo.h should undefine those symbols (NORETURN and PRINTFLIKE) at the end, or give them a XO_ namespace prefix. I'll fix it up locally and keep testing, but we need some solution for this before committing. (Or am I doing something wrong?)

$ sudo dtrace -n 'BEGIN { mod(0xffffffff8261a000); exit(0); }'
dtrace: description 'BEGIN ' matched 1 probe
CPU ID FUNCTION:NAME

6      1                           :BEGIN

opensolaris.ko

In D41745#951971, @domagoj.stolfa_gmail.com wrote:

In D41745#951858, @stephane.rochoy_stormshield.eu wrote:

I suggest to think about adding --libxo foo as an alias to -x oformat=foo to make things more inline with what is actually done for, e.g., netstat(1).

Thanks for the feedback! I don't take a strong view on whether or not xo_parse_args() should be called at the start, though it might require some finessing to make it work happily with libdtrace because xo_parse_args() sets a number of flags for libxo that I don't with -x oformat (such as colored output in some cases). Another thing worth pondering is that this is also an argument to libdtrace rather than dtrace(1), so one would inevitably need to still call dtrace_setopt(). Now, however libxo configuration would be performed twice: once in dtrace(1), and once in libdtrace. dtrace(1) itself would explicitly need to include libxo and link against it, but this isn't a big issue IMO, it just "feels" cleaner to me for it to only link against libdtrace and for libdtrace to provide all the libxo handling and configuration and for any consumer code (including dtrace(1)) to simply request it.

However I do agree with the general point that there is an inconsistency with the rest of the base system when it comes to libxo integration (though it's inconsistent in a fair bit of other ways too). One way to work around the issue without xo_parse_args() would be perhaps to add a - flag and manually parse out the -libxo ... that follows? I'm not sure what the best approach would be that doesn't get slightly messy.

Looks good. FWIW, the fix in the repo is in commit de776ab1a8985fbeb510af8e39777fa9db69d3d9:

Sorry for the delay.

While I have fond memories of snobol, I'm thinking you've got the wrong "phil".

These are in the libxo sources on github:

Looks good. I do see an error on this site that says some nameless file is missing a terminating newline.

One more thing: Does libxo need an xo_exit() function? It would be just xo_finish + exit, like your EXIT macro, but might help minimize diffs like this.

xo_parse_args gives error messages for invalid arguments; no further error is needed.

Cameron,

You said "it seems that most check"; did you find ones that didn't?

Yes, you need to check it. See xo_parse_args(3):

In D30350#687710, @me_cameronkatri.com wrote:

I could swear I tried this, I’ll update the patch shortly.

In D30350#681699, @me_cameronkatri.com wrote:

Run xo_finish(3) after all instances of xo_errx(3)

FYI: I've just added docs for this, so it will be in the next release, which I'll import shortly, but the functionality's already there.

Looks good. You can use {L:} for strings that include slashes by escaping them with double backslashes (one for C, one for me):

Correction: for your patch the test would be opposite:

Apologies, I missed your reply to my question, but it's still something I'm not following:

Looks good. I'll mirror these fixes in github.

The "%hs" bits look good, but why do you add the call to xo_no_setlocale()?

Just knowing that the "--libxo" was used is not sufficient, since there are options that should not affect output (e.g. color, no-humanize, warn).

Looks great! Thanks....

Strange error; libtool related. On some platforms it seems to remove the ".test" extension. I'll add a fix to libxo to force removal of the extension (using xo_program() to set it to the basename), but for now, the fix here will be fine.

The responsibility for valid tags should rest with the caller, but under the "never do the wrong thing", I'll pick up this fix, along with a "warning" call to help coders notice the breakage.

Looks good. Thanks....

FWIW, this bug is mine, from the original patch sets:

Thanks!!