GNU libtool checks the output from invoking the linker with --version
and --help, in order to determine the linker "flavour" and the command-
ine arguments to use for various link operations (e.g. generating shared
libraries). To detect GNU ld it looks for the strings "GNU" and
"supported targets:.*elf". Since LLD is compatible with GNU ld we
include those same strings to fool libtool.
Quoting from a comment in the change:
This is somewhat ugly hack, but in reality, we had no choice other
than doing this. Considering the very long release cycle of Libtool,
it is not easy to improve it to recognize LLD as a GNU compatible
linker in a timely manner. Even if we can make it, there are still a
lot of "configure" scripts out there that are generated by old
version of Libtool. We cannot convince every software developer to
migrate to the latest version and re-generate scripts. So we have
this hack.
Upstream LLVM revisions r298532, r298568, r298591
Obtained from: LLVM
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
The change introduced a dependency between genassym.c and header files
generated from .m files, but that dependency is not specified in the
make files.
Also, the change could be not as useful as I thought it was.
Reported by: dchagin, Manfred Antar <null@pozo.com>, and many others
that used to work via the bold hack).
Fix the table entry for bright black. Fix spelling of plain black in
nearby table entries (use the macro for black everywhere everywhere).
Fix the currently-unused non-bright color table to not have bright
colors in entries 9-15.
Improve nearby comments. Start converting to the xterm terminology
and default rendering of "bright" instead of "light" for bright
colors.
Syscons wasn't affected by the bug since I optimized it a little by
converting colors 0-15 directly. This also fixes the layering of
the conversion for these colors.
Apply the same optimization to vt (actually the layer above it). This
also moves the conversion 1 closer to the correct layer for colors
0-15.
The optimization of just avoiding 2 calls to a trivial function is worth
about 10% for simple output to the virtual buffer with occasional
rendering. The optimization is so large because the 2 calls are done
on every character, so although there are too many other calls and
other instructions per character, there are only about 10 times as
many. Old versions of syscons were about 10 times faster for simple
output, by using a fast path with about 12 instructions per character.
Rendering to even slow hardware takes relatively little time provided
it is rarely actually done.
database in the kernel audit implementation, similar the exist
class mapping database. This will be used by the DTrace audit
provider to map audit event identifiers originating in the
system-call table back into strings for the purposes of setting
probe names. The database is initialised and maintained by
auditd(8), which reads values in from the audit_events
configuration file, and then manages them using the A_GETEVENT
and A_SETEVENT auditon(2) operations.
Obtained from: TrustedBSD Project
Sponsored by: DARPA, AFRL
MFC after: 3 weeks
The change seems to be more in the nomenclature than in the way the
topology is advertised by the hardware.
Tested by: truckman (earlier version of the change)
MFC after: 2 weeks
Implement timeouts for register-based DMAR commands. Tunable/sysctl
hw.dmar.timeout specifies the timeout in nanoseconds, set it to zero
to allow infinite wait. Default is 1ms.
Runtime modification of the sysctl is not safe, it is allowed for
debugging.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
- Add a new "qsize" parameter in audit_control and the getacqsize(3) API to
query it, allowing to set the kernel's maximum audit queue length.
- Add support to push a mapping between audit event names and event numbers
into the kernel (where supported) using new A_GETEVENT and A_SETEVENT
auditon(2) operations.
- Add audit event identifiers for a number of new (and not-so-new) FreeBSD
system calls including those for asynchronous I/O, thread management, SCTP,
jails, multi-FIB support, and misc. POSIX interfaces such as
posix_fallocate(2) and posix_fadvise(2).
- On operating systems supporting Capsicum, auditreduce(1) and praudit(1) now
run sandboxed.
- Empty "flags" and "naflags" fields are now permitted in audit_control(5).
Many thanks to Christian Brueffer for producing the OpenBSM release and
importing/tagging it in the vendor branch. This release will allow improved
auditing of a range of new FreeBSD functionality, as well as non-traditional
events (e.g., fine-grained I/O auditing) not required by the Orange Book or
Common Criteria.
Obtained from: TrustedBSD Project
Sponsored by: DARPA, AFRL
MFC after: 3 weeks
Weiming Zhao):
builtins: Select correct code fragments when compiling for Thumb1/Thum2/ARM ISA.
Summary:
Value of __ARM_ARCH_ISA_THUMB isn't based on the actual compilation
mode (-mthumb, -marm), it reflect's capability of given CPU.
Due to this:
- use __tbumb__ and __thumb2__ insteand of __ARM_ARCH_ISA_THUMB
- use '.thumb' directive consistently in all affected files
- decorate all thumb functions using
DEFINE_COMPILERRT_THUMB_FUNCTION()
---------
Note: This patch doesn't fix broken Thumb1 variant of __udivsi3 !
Reviewers: weimingz, rengolin, compnerd
Subscribers: aemerson, dim
Differential Revision: https://reviews.llvm.org/D30938
Discussed with: mmel
X-MFC-With: r314564
Show nanoseconds in the -u/-c header line.
The present portability conditionals cannot handle the POSIX standard
st_mtim, so remove them and unconditionally use st_mtim.
PR: 218018
Reported by: jbeich
Reviewed by: bapt
Differential Revision: https://reviews.freebsd.org/D10145
I fixed this in 1997, but the fix was over-engineered and fragile and
was broken in 2003 if not before. i386 parameters were copied to 8
other arches verbatim, mostly after they stopped working on i386, and
mostly without the large comment saying how the values were chosen on
i386. powerpc has a non-verbatim copy which just changes the uncritical
parameter and seems to add a sign extension bug to it.
Just treat negative offsets as offsets if they are no more negative than
-db_offset_max (default -64K), and remove all the broken parameters.
-64K is not very negative, but it is enough for frame and stack pointer
offsets since kernel stacks are small.
The over-engineering was mainly to go more negative than -64K for the
negative offset format, without affecting printing for more than a
single address.
Addresses in the top 64K of a (full 32-bit or 64-bit) address space
are now printed less well, but there aren't many interesting ones.
For arches that have many interesting ones very near the top (e.g.,
68k has interrupt vectors there), there would be no good limit for
the negative offset format and -64K is a good as anything.
implemented in top(1), rather than relying on K&R prototypes, which can
cause problems on targets where there are multiple incompatible calling
conventions and the compiler requires argument information to select the
correct one.
(There's a bit more to do here, since it looks like top(1) also sometimes
provides prototypes for various curses functions rather than relying on
the header file...)
Sponsored by: DARPA, AFRL
MFC after: 1 week
1) They are using wrong tag (Tx) + map (Rx) combination.
2) Rx descriptor is already synchronized in iwn_notif_intr()
3) It's not needed for transmitted data since device does not change
mbuf contents.
Tested with Intel 6205 (amd64), STA mode.
locally defined K&R prototypes in .c files; use appropriate casts for
pointer types now that types for arguments are available at compile time.
This ensures that compilers with multiple incompatible calling conventions
can select the correct calling convention for external functions.
Sponsored by: DARPA, AFRL
MFC after: 1 week
Newer VGAs don't support any mono modes, but bugs in the tables created
2 virtual mono modes (#45 90x43 and #112 80x43) that behaved more
strangely than crashing. 90-column modes are tweaked 80-column ones
and also fail to work on newer VGAs. #45 did crash (hang) on some
hardware.
it to a separate state for each CPU.
Terminal "input" is user or kernel output. Its state includes the current
parser state for escape sequences and multi-byte characters, and some
results of previous parsing (mainly attributes), and in teken the cursor
position, but not completed output. This state must be switched for kernel
output since the kernel can preempt anything, including itself, and this
must not affect the preempted state more than necessary. Since vty0 is
shared, it is necessary to affect the frame buffer and cursor position and
history, but escape sequences must not be affected and attributes for
further output must not be affected.
This used to work. The syscons terminal state contained mainly the parser
state for escape sequences and attributes, but not the cursor position,
and was switched. This was first broken by SMP and/or preemptive kernels.
Then there should really be a separate state for each thread, and one more
for ddb, or locking to prevent preemption. Serialization of printf() helps.
But it is arcane that full syscons escape sequences mostly work in kernel
printf(), and I have never seen them used except by me to test this fix.
They worked perfectly except for the races, since "input" from the kernel
was not special in any way.
This was broken to use teken. The general switch was removed, and the
kernel normal attribute was switched specially. The kernel reverse
attribute (config option SC_CONS_REVERSE_ATTR) became unused, and is
still unusable because teken doesn't support default reverse attributes
(it used to only be used via the ANSI escape sequence to set reverse
video).
The only new difficulty for using teken seems to be that the cursor
position is in the "input" state, so it must be updated in the active
input state for each half of the switch. Do this to complete the
restoration.
The per-CPU state is mainly to make per-CPU coloring work cleanly, at
a cost of some space. Each CPU gets its own full set of attribute
(not just the current attribute) maintained in the usual way. This
also reduces races from unserialized printf()s. However, this gives
races for serialized printf()s that otherwise have none. Nothing
prevents the CPU doing the a printf() changing in the middle of an
escape sequence.
optimization.
This fixes building with gcc-4.2.1 (it doesn't support SSE4).
gas-2.17.50 [FreeBSD] supports SSE4 instructions, so this doesn't
need using .byte directives.
This fixes depending on host user headers in the kernel.
Fix user includes (don't depend on namespace pollution in <nmmintrin.h>
that is not included now).
The instrinsics had no advantages except to sometimes avoid compiler
pessimixations. clang understands them a bit better than inline asm,
and generates better looking code which also runs better for cem, but
for me it just at the same speed or slower by doing excessive
unrollowing in all the wrong places. gcc-4.2.1 also doesn't understand
what it is doing with unrolling, but with -O3 somehow it does more
unrolling that helps.
Reduce 1 of the the compiler pessimizations (copying a variable which
already satisfies an "rm" constraint in a good way by being in memory
and not used again, to different memory and accessing it there. Force
copying it to a register instead).
Try to optimize the inner loops significantly, so as to run at full
speed on smaller inputs. The algorithm is already very MD, and was
tuned for the throughput of 3 crc32 instructions per cycle found on
at least Sandybridge through Haswell. Now it is even more tuned for
this, so depends more on the compiler not rearranging or unrolling
things too much. The main inner loop for should have no difficulty
runing at full speed on these CPUs unless the compiler unrolls it too
much. However, the main inner loop wasn't even used for buffers smaller
than 24K. Now it is used for buffers larger than 384 bytes. Now it
is not so long, and the main outer loop is used more. The new
optimization is to try to arrange that the outer loop runs in parallel
with the next inner loop except for the final iteration; then reduce
the loop sizes significantly to take advantage of this.
Approved by: cem
Not tested in production by: bde
Some code was additionally moved for (future) lock splitting.
Tested with Intel 6205, STA mode.
Differential Revision: https://reviews.freebsd.org/D10106
We don't have enouch space to store full VFP context within mcontext
stucture. Due to this:
- follow i386/amd64 way and store VFP state outside of the mcontext_t
but point to it. Use the size of VFP state structure as an 'magic'
indicator of the saved VFP state presence.
- teach set_mcontext() about this external storage.
- for signal delivery, store VFP state to expanded 'struct sigframe'.
Submited by: Andrew Gierth (initial version)
PR: 217611
MFC after: 2 weeks
Kernel environment variable hw.busdma.default can take values 'bounce'
and 'dmar' and selects corresponding busdma backend as default.
Per-device environment variable hw.busdma.pci<domain>.<bus>.<slot>.<func>
takes the same values and overrides hw.busdma.default for the given device.
Note that even with hw.busdma.default=bounce, DMA translation engines
are still started if DMARs are enabled, to disable them use
hw.dmar.dma tunable, as before.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
FreeBSD uses upstream DTB for RPi3 build and compatibility string for
i2c device is different there. Add this new string to compatibility data.
Reported by: Karl Denninger
MFC after: 3 days
Do not try to use errno(2) codes here; instead, just return unique
value (1) when radio is disabled via hardware switch and another
one (-1) for any other error in initialization path.
Tested with Intel 6205, STA mode.
The change is more intrusive than I would like because the feature
requires that a vector number is written to a special register.
Thus, now the vector number has to be provided to lapic_eoi().
It was readily available in the IO-APIC and MSI cases, but the IPI
handlers required more work.
Also, we now store the VMM IPI number in a global variable, so that it
is available to the justreturn handler for the same reason.
Reviewed by: kib
MFC after: 6 weeks
Differential Revision: https://reviews.freebsd.org/D9880
ip_forward, TCP/IPv6, and probably SCTP leaked references to L2 cache
entry because they used their own routes on the stack, not in_pcb routes.
The original model for route caching was callers that provided a route
structure to ip{,6}input() would keep the route, and this model was used
for L2 caching as well. Instead, change L2 caching to be done by default
only when using a route structure in the in_pcb; the pcb deallocation
code frees L2 as well as L3 cacches. A separate change will add route
caching to TCP/IPv6.
Another suggestion was to have the transport protocols indicate willingness
to use L2 caching, but this approach keeps the changes in the network
level
Reviewed by: ae gnn
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D10059
and those below, will be ignored--
> Description of fields to fill in above: 76 columns --|
> PR: If and which Problem Report is related.
> Submitted by: If someone else sent in the change.
> Reported by: If someone else reported the issue.
> Reviewed by: If someone else reviewed your modification.
> Approved by: If you needed approval for this commit.
> Obtained from: If the change is from a third party.
> MFC after: N [day[s]|week[s]|month[s]]. Request a reminder email.
> MFH: Ports tree branch name. Request approval for merge.
> Relnotes: Set to 'yes' for mention in release notes.
> Security: Vulnerability reference (one per line) or description.
> Sponsored by: If the change was sponsored by an organization.
> Differential Revision: https://reviews.freebsd.org/D### (*full* phabric URL needed).
> Empty fields above will be automatically removed.
M netinet/in_pcb.c
M netinet/ip_output.c
M netinet6/ip6_output.c
