79ad79d6 ed Aug. 21, 2016, 4:02 p.m.
240f8c2d ed Aug. 21, 2016, 4:01 p.m.
Essentially, this is a literal copy of the code in sys/compat/cloudabi64,
except that it now makes use of 32-bits datatypes and limits. In
sys/conf/files, we now need to take care to build the code in
sys/compat/cloudabi if either COMPAT_CLOUDABI32 or COMPAT_CLOUDABI64 is
turned on.

This change does not yet include any of the CPU dependent bits. Right
now I have implementations for running i386 binaries both on i386 and
x86-64, which I will send out for review separately.
cgit ViewVC
df71f1dc ed Aug. 21, 2016, 3:56 p.m.
We should pull in the 32 bit headers when using this system call table.
cgit ViewVC
98d627a0 ed Aug. 21, 2016, 3:41 p.m.
9d7777e1 bjk Aug. 21, 2016, 3:39 p.m.
The driver was removed by jhb in r304513, and the &hwlist.ie; entity
is no longer generated, causing the website build to fail.
cgit ViewVC
90f4145f ed Aug. 21, 2016, 3:37 p.m.
Without it, we only obtain the ELF types native to the system. In this
we explicitly want the 64-bit versions.
cgit ViewVC
47cb4d7b ed Aug. 21, 2016, 3:36 p.m.
Right now we're casting uint64_t's to native pointers. This isn't
causing any problems right now, but if we want to provide a 32-bit
compatibility layer that works on 64-bit systems as well, this will
cause problems. Casting a uint32_t to a 64-bit pointer throws a compiler
error.

Introduce a TO_PTR() macro that casts the value to uintptr_t before
casting it to a pointer.
cgit ViewVC
4fbc9065 ed Aug. 21, 2016, 3:14 p.m.
It turns out that it works perfectly fine for generating 32-bits vDSOs
as well. While there, get rid of the extraneous .s file extension.
cgit ViewVC
a953f555 ed Aug. 21, 2016, 9:32 a.m.
Though uio_resid is of type ssize_t, we need to take into account that
this source file contains an implementation specific to a certain
userspace pointer size. If this file provided 32-bit implementations,
this should have used INT32_MAX, even when running a 64-bit kernel.

This change has no effect, but is simply in preparation for adding
support for running 32-bit CloudABI executables.
cgit ViewVC
384ef484 ed Aug. 21, 2016, 7:41 a.m.
On 32-bit platforms, our 64-bit timestamps need to be split up across
two registers. A simple assignment to td_retval[0] will cause the top 32
bits to get lost. By using memcpy(), we will automatically either use 1
or 2 registers depending on the size of register_t.
cgit ViewVC
7ce07161 ed Aug. 21, 2016, 7:28 a.m.
The reason why the old vDSOs were written in C using inline assembly was
purely because they were embedded in the C library directly as static
inline functions. This was practical during development, because it
meant you could invoke system calls without any library dependencies.
The vDSO was simply a copy of these functions.

Now that we require the use of the vDSO, there is no longer any need for
embedding them in C code directly. Rewriting them in assembly has the
advantage that they are closer to ideal (less useless branching, less
assumptions about registers remaining unclobbered by the kernel, etc).
They are also easier to build, as they no longer depend on the C type
information for CloudABI.

Obtained from:	https://github.com/NuxiNL/cloudabi
cgit ViewVC
1a71a7f2 adrian Aug. 21, 2016, 12:48 a.m.
This was .. an interesting headache.

There are two halves:

* The earlier IRIX stuff (yes, early) occasionally would do dead
  code removal and generate multiple consecutive LO16 entries.
  If this is done for REL entries then it's fine - there's no
  state kept between them.  But gcc 5.x seems to do this for
  RELA entries.

eg:

HI1 LO1 HI2 LO2 LO3 HI4 LO4

.. in this instance, LO2 should affect HI2, but LO3 doesn't at all
affect anything.  The matching HI3 was in code that was deleted
as "dead code".

Then, the next one:

* A "GCC extension" allows for multiple HI entries before a LO entry;
  and all of those HI entries use the first LO entry as their basis
  for RELA offset calculations.

It does this so GCC can also do dead code deletion without necessarily
having to geneate fake relocation entries for balanced HI/LO RELA
entries.

eg:

HI1 LO1 HI2 HI3 HI4 LO4 LO5 HI6 LO6 LO7

in this instance, HI{2,3,4} are the same relocation as LO4 (eg .bss)
and need to be buffered until LO4 - then the RELA offset is applied
from LO4 to HI{2,3,4} calculations.

/And/, the AHL from HI4 is used during the LO4 relocation calculation,
just like in the normal (ie, before this commit) implementation.

Then, LO5 doesn't trigger anything - the HI "buffer" is empty,
so there are no HI relocations to flush out.

HI6/LO6 are normal, and LO7 doesn't trigger any HI updates.

Tested:

* AR9344 SoC, kernel modules, using gcc-5.3 (mips-gcc-5.3.0 package)

Notes:

* Yes, I do feel dirty having written this code.

Reviewed by:	imp (after a handful of "this should be on fire" moments wrt gcc and this code)
cgit ViewVC
9da85a91 zec Aug. 20, 2016, 10:12 p.m.
The default value of the tunable introduced in r304436 couldn't be
effectively overrided on VIMAGE kernels, because instead of being
accessed via the appropriate VNET() accessor macro, it was accessed
via the VNET_NAME() macro, which resolves to the (should-be) read-only
master template of initial values of per-VNET data.  Hence, while the
value of udp_require_l2_bcast could be altered on per-VNET basis, the
code in udp_input() would ignore it as it would always read the default
value (one) from the VNET master template.

Silence from: rstone
cgit ViewVC
703f2cb2 dim Aug. 20, 2016, 9:34 p.m.
va_start() on the 'which' parameter of nvlist_prtctl_dofmt().
cgit ViewVC
db727c1b karels Aug. 20, 2016, 8:46 p.m.
The ip6_output routine is missing L2 cache invalication as done
in ip_output.  Even with that code, some problems with UDP over
IPv6 have been reported.  Diabling L2 cache for that problem works
around the problem for now.

PR:		211872 211926
Reviewed by:	gnn
Approved by:	gnn (mentor)
MFC after:	immediate
cgit ViewVC