These libraries have the special feature that they install both the .a
library as well as the .a.syms that is generated from them. To avoid
the transformation rule .a.a.syms to apply to the files in ${DESTDIR},
that rule has to be disabled during the installation phase.
If the transformation rule were active during installation, the .a.syms
file in ${DESTDIR} would have more than one possible source file, which
eventually leads to an error during installation since in the command
"install a b c", the last argument must be a directory, not a file.
The installation phase should be as minimal as possible anyway,
therefore move the generation of the .syms files to the build phase.
This hopefully fixes the build for HAVE_LLVM=yes, which has been broken
for several weeks now, at least for the official builds.
- allow attributes after labels (for unused)
XXX: split the attributes into function, variable, etc attributes
so that we don't accept all attributes in all places (only where they make
sense)
don't have any useful device child nodes:
aliases
options
openprom
chosen
packages
...and also allow machdep additions to this list (XXX which are temporarily
declared here for arm32 until there's a consistent machine/ofw_machdep.h
header file).
I2C interface is implemented by bit-banging a couple of GPIO pins on
the Sequoia core logic used in the Shark.
Heavy lifting by Julian Coleman, and minor tweaks and a different
autoconfiguration scheme by me.
the details of what's going on (disable / restore interrupts), and
use it consistently.
- Give "sequoia" a device_t in the system device tree, matching on
the Shark's /vlbus/isa node, acting a subclass of ofisa (an "ofisa"
will be attached to "sequoia"). This allows us to attach other logical
device nodes to the "sequoia".
than PAGE_SIZE and fails spuriously.
XXX: Note the duplicate definition hacks. Should really create <x86/gdt.h>,
put the just the constants there and unify them.
This would also avoid the hack in: src/tests/lib/libi386/t_user_ldt.c#46
In principle this might just push a real problem around, but this is
unlikely to be a real problem because:
1. The large stack frames are really only in the setup state machine
message handlers, which run at the top loop of a thread with a
shallow stack anyway.
2. If these are inlined, gcc might create multiple nonoverlapping
stack buffers, whereas if not inlined, the stack frames from
consecutive or alternative procedure calls would overlap anyway.
(I haven't investigated exactly what's going on leading to ~5 KB-byte
stack frames, but this shuts gcc up, at least, and the hypotheses
sound plausible to me!)
