[Raion]

A somewhat insignificant topic, but it's worth discussing.

For those not familiar, IRIX uses nroff, a version of the UNIX roff/troff manpage formatter. It has not aged as well, and there's questions of maintainability because some programs already don't see nroff on IRIX as suitable for installing manpages.

Thus, we need a consensus on what to replace it with.

Let me start with the three most obvious contenders:

Heritage Tools nroff (based on OpenSolaris nroff)
GNU Groff
Mandoc (BSD-based)

Personally, I am currently working to port HT nroff/troff to IRIX. The reason why is that it's nearly identical as the shipped version, so it shouldn't break any stock IRIX manpages, and this is my selection of what I believe is best.

That being said, Groff and mandoc are also options here. I personally do not want to use groff because it does glitch out on some IRIX manpages for me when I compiled it. I'm also not keen on the performance of groff.

I'm okay with mandoc, but I haven't researched it, so I have zero idea if it's acceptable with IRIX manpages. 

If you have an opinion on what we should go with, by all means.

[commodorejohn]

My general opinion is "whatever breaks things the least."

[Raion]

From looking at the code of mandoc, that appears to be the most "drastic".

I will be experimenting with all three myself.

[jpstewart]

It's important to remember that nroff wasn't included in the base IRIX install.  Pre-formatted man pages were shipped, instead.  To get nroff, you had to install the "Documenter's Workbench" stuff from an additional CD.  Even then, the man command would still use the pre-formatted pages when they were available.  So no matter what you replace nroff with, there is little to no chance of breaking the basic system man pages.

IRIX came with "awf" the "Amazingly Workable Formatter" to format man pages from sources that didn't provide them pre-formatted.  So even if the replacement to nroff does break something, there's always awf as a fallback that is installed as part of a default IRIX setup.

[Raion]

For now, I've settled on mandoc. It compiles out of the box on IRIX with only a c99 compliant GCC (it doesn't like some GCCisms, which could probably be fixed down the line)

If there's any objections or concerns, speak now (I won't make you hold your peace, but it would be a nasty issue if we didn't address your concerns!)

This is preferable to gnu groff. Heritage Doctools has too many UnixWare-isms that will take a long time to fix. It not liking either GNU flex or IRIX flex was the end for me.

[Raion]

So trying to get mandoc compiling with MIPSPro has been hard. Mandoc itself seems to work fine, but the makewhatis script breaks down. Here's the mipspro patch I have:

Code:

diff -urnp mandoc-1.14.5/configure mandoc-1.14.5-patched/configure
*** mandoc-1.14.5/configure     Sun Mar 10 05:56:43 2019
--- mandoc-1.14.5-patched/configure     Sun May 31 16:30:00 2020
*************** OSENUM=
*** 41,48 ****
  OSNAME=
  UTF8_LOCALE=

! CC=`printf "all:\\n\\t@echo \\\$(CC)\\n" | env -i make -sf -`
! CFLAGS=
  LDADD=
  LDFLAGS=
  LD_NANOSLEEP=
--- 41,48 ----
  OSNAME=
  UTF8_LOCALE=

! CC=c99
! CFLAGS='-O3 -mips3 '
  LDADD=
  LDFLAGS=
  LD_NANOSLEEP=
diff -urnp mandoc-1.14.5/mandoc.h mandoc-1.14.5-patched/mandoc.h
*** mandoc-1.14.5/mandoc.h      Sun Mar 10 05:56:43 2019
--- mandoc-1.14.5-patched/mandoc.h      Sun May 31 16:25:43 2020
*************** enum mandocerr    mandoc_msg_getmin(void)
*** 279,286 ****
  void            mandoc_msg_setmin(enum mandocerr);
  enum mandoclevel  mandoc_msg_getrc(void);
  void            mandoc_msg_setrc(enum mandoclevel);
! void            mandoc_msg(enum mandocerr, int, int, const char *, ...)
!                       __attribute__((__format__ (__printf__, 4, 5)));
  void            mchars_alloc(void);
  void            mchars_free(void);
  int             mchars_num2char(const char *, size_t);
--- 279,285 ----
  void            mandoc_msg_setmin(enum mandocerr);
  enum mandoclevel  mandoc_msg_getrc(void);
  void            mandoc_msg_setrc(enum mandoclevel);
! void            mandoc_msg(enum mandocerr, int, int, const char *, ...);
  void            mchars_alloc(void);
  void            mchars_free(void);
  int             mchars_num2char(const char *, size_t);
diff -urnp mandoc-1.14.5/mandoc_aux.h mandoc-1.14.5-patched/mandoc_aux.h
*** mandoc-1.14.5/mandoc_aux.h  Sun Mar 10 05:56:43 2019
--- mandoc-1.14.5-patched/mandoc_aux.h  Sun May 31 16:33:09 2020
***************
*** 16,23 ****
   * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
   */

! int             mandoc_asprintf(char **, const char *, ...)
!                       __attribute__((__format__ (__printf__, 2, 3)));
  void           *mandoc_calloc(size_t, size_t);
  void           *mandoc_malloc(size_t);
  void           *mandoc_realloc(void *, size_t);
--- 16,22 ----
   * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
   */

! int             mandoc_asprintf(char **, const char *, ...);
  void           *mandoc_calloc(size_t, size_t);
  void           *mandoc_malloc(size_t);
  void           *mandoc_realloc(void *, size_t);

I'm aware I should probably figure out how to migrate the __attribute blocks, but this is purely for testing. 

The makewhatis segfaults when trying to update the mandoc.db:

Code:

root@passionlip ~/mandoc-1.14.5 % /opt/xeno/sbin/makewhatis /usr/share/man
Segmentation fault (core dumped)
root@passionlip ~/mandoc-1.14.5 % dbx /opt/xeno/sbin/makewhatis
dbx version 7.3.7 (96015_Nov16 MR) Nov 16 2004 07:34:16
Executable /opt/xeno/sbin/makewhatis
(dbx) r /usr/share/man
Process 62463 (makewhatis) started
Process 62463 (makewhatis) stopped on signal SIGSEGV: Segmentation violation (default) at [memcpy:357 ,0xfa5065c]
         Source (of /xlv86/patches/7204/work/irix/lib/libc/libc_n32_M4/strings/bcopy.s) not available for Process 62463

When I have dbx show me where: https://pastebin.com/at2SN2Ur

I have tried uninstalling that patch. it just shifts it to the same file elsewhere. I'm not sure what's going on and I don't have enough experience to know. 

Halp?

[jpstewart]

[Disclaimer:  the following is based on only a quick glance at the pastebin output and the mandoc code.  This is what jumped out at me immediately.  So I may be completely missing something here.]

The reference to strings/bcopy.s in the output is a red herring.  That's part of IRIX libc's internal code, and thus not something we can or should debug.  But it does suggest that libc has received parameters it didn't expect and has done something weird with them.

Looking at the pastebin file, line 7 (in pastebin's numbering scheme;  line 5 of the dbx trace) we see that mandoc_asprintf was called with a fmt argument of "%zun".  (The next line tells us that in turn came from the rewrite_macro2len function on line 1651 of mdoc_validate.c, so that's where the problem originated.)

The "%zun" format specifier to the printf family of functions is problematic for us.  Newer libc implementations (GNU, BSD, ...) use the "z" character as a length modifier to indicate the following "u" argument is of type size_t.  IRIX libc doesn't support the "z" length modifier at all.  So that's got to go, for starters.  I'm assuming you're compiling as N32 code, so an unmodified "%u" should suffice since size_t is defined as an unsigned int in /usr/include/sys/types.h.  (Use %lu for 64-bit code where size_t is an unsigned long instead.  Which clearly shows why the z modifier is needed for portable code!)

Also, the trailing "n" is potentially problematic.  I'm not 100% sure, but I think the code is intended to print a size_t followed by a literal "n".  But IRIX libc seems to be interpreting it as the "n" "conversion character" which requests the printf family of functions to put the length of the printed string into a variable.  But the next argument to the printf call (from mdoc_validate.c) is an int rather than a pointer to an int.  That would explain the segmentation fault:  printf treating that integer as a pointer means it is trying to write to memory the process doesn't own. 

I don't know at the moment if simply removing the z from the format string (in mdoc_validate.c) will be sufficient for IRIX libc to properly parse that the trailing "n" is a literal "n" or how else the altered format might get (mis-)parsed.  But for sure the "z" has to go.  If it still fails, then there are other ways to get a literal "n" in the right spot in the output.

[Raion]

Gotcha that makes a lot of sense.

I have never encountered this sort of issue with any libc printf(); implementation before so I was not sure what the hell was going on. Hopefully the attribute removal does not play into the problem here.

Worst case you think it would be a good idea to grab a newer printf() function from a BSD and override the irix stdio.h with that? I dunno, just bikeshedding here.

[jpstewart]

Worst case you think it would be a good idea to grab a newer printf() function from a BSD and override the irix stdio.h with that? I dunno, just bikeshedding here.

Probably not worth the effort.  Grepping the mandoc source code, there's only the one instance of the "%zun" sequence to worry about.  If, after removing the "z", IRIX still can't parse it as "%u" followed by a literal "n", I'd just change it to:

Code:

mandoc_asprintf(arg, "%u%c", width, 'n');

That should get the job done with no ambiguity parsing "n" as a literal character vs. "n" as printf conversion character.

There are also 25 other "%zu" occurrences in 5 other files that will also need to have the "z" removed.  But that only takes a couple minutes.

[Raion]

That fixed it!