rebase

GNU as 2.17.50 assembles this identically to the unpatched version; IMO you should commit this now, and you or I can follow up with the build infrastructure change.

godbolt shows one inconsequential difference between clang & gcc:

--- clang.txt   2020-06-05 08:29:34.207545000 -0400
+++ gcc.txt     2020-06-05 08:29:58.341321000 -0400
@@ -1866,8 +1866,8 @@
  mov    QWORD PTR [rbp+0xc0],rcx
  mov    r9,QWORD PTR [rdi+0x18]
  jmp    1bc0 <Skein1024_block_loop>
- nop    WORD PTR cs:[rax+rax*1+0x0]
- nop    DWORD PTR [rax+0x0]
+ data16 nop WORD PTR cs:[rax+rax*1+0x0]
+ nop    DWORD PTR [rax]
 Skein1024_block_loop:
  mov    r8,QWORD PTR [rdi+0x10]
  add    r8,QWORD PTR [rbp+0xc0]

This looks reasonable to me. We'll need to bring in a couple of LLVM commits to be able to test.

Following up after discussions on IRC, the canonical way do do this is:
CFLAGS=-fPIC
LDFLAGS=-pic
or if compiling a test app on the command line,
cc -fPIC -pic ...

Problem is that all drivers link with crt1.o instead of Scrt1.o. See r200038.

lld 10 refuses to link with -fPIE -Wl,--pie with errors like

ld: error: cannot preempt symbol: _DYNAMIC
>>> defined in 
>>> referenced by crt1.c:62 (/usr/home/emaste/src/freebsd-svn/head/lib/csu/amd64/crt1.c:62)
>>>               /usr/lib/crt1.o:(_start)
...

I'm a little confused, should this not just be a vendor update of OpenBSM? In come circumstances we might cherry-pick an individual fix or two into contrib/, but in general I'd expect to see a wholesale update to a newer release/snapshot.

@lstewart sorry I missed your question earlier, but it looks like there was sufficient commentary

I noticed one nit - after clearing history you can press Scroll Lock and scroll up through the cleared history buffer, while we probably want to reset that as well. However, I'd suggest that you commit this now and we can address that in a followup. I also did not check how sc(4) behaves with respect to this.

Some time ago I started a thread on FreeBSD-stable to ask if there are any users and received no responses.

@glebius were you able to find out anything?

Could make the flags bool instead of int

At this point BINUTILS is enabled only on i386 and amd64, BINUTILS_BOOTSTRAP only on amd64.

OK, fair enough. Another question, what is the downside of building regular yacc with YYBTYACC?

Seems reasonable to me, although I'm curious about the use cases

In D24945#549333, @jmg wrote:

If you want to test, you generate a self sign cert:

I can remove this pre-commit if consensus moves in that direction.

Will you refresh this review now that the library is in vendor (and merged to contrib)?

In D24596#547800, @pi wrote:

These types of greps on a linux system return an error message for every directory in the directory you ran the grep in

So if we modify grep to not try to read directories and not spew errors, would that be a solution ?

This is fine with me

I do wonder what the impact of changing l_addr would actually be

rS361099

We should also check the other modules -- for example, ftp and irc are in common use; I'm not sure off hand what skinny and smedia are.

Do we need to request an up-to-date exp-run?

It looks like we should be able to do away with it