All changes to the global variable 'dcs' are tracked now, to help
identify the cause of the failing tests in expr_sizeof and
gcc_attribute_aligned.
While here, test more invalid type combinations in typedefs.
Even though the test only uses fixed-size types, lint's computed size of
the resulting struct differs between i386 (80) and x86_64 (112). Both
are wrong, probably due to the unrelated struct declaration above, as
already mentioned in the comments.
integers (10^50 or so), so we don't exceed the capacity of systems where
long int is only 32 bits.
Hopefully will unbreak the i386 build, perhaps others.
This uses inputs that can't be distinguished with only 53 bits of
precision, so it should work in essentially all long double formats
to detect when nearbyintl is incorrectly implemented in terms of
nearbyint.
PR lib/58054
The macro 'offsetof(t, m)' already expanded to a constant expression for
scalar members but not for arrays. This was because the macro expanded
to '(size_t)(((t *)0)->m)', which lint internally represents as
'addr(indir(ptr(0) + offset(m)))', and build_address simplifies
'addr(indir(x))' to 'x' if the types match. The types only match for
scalar types though, but not for arrays.
When build_address happens, the type information is incomplete,
therefore 'offsetof(t, array)' has to be simplified at a later point.
This test is skipped in most circumstances because it creates a file
whose apparent size is 4.5 GB. It's an ISO 9660 image though,
containing mostly null bytes. Nevertheless, tmpfs doesn't allow such a
big file to be created, so this test is skipped in settings where /tmp
is on a tmpfs.
If the test is run, the ISO image is uncompressed, which takes several
minutes. Replace bzip2 with direct file creation from a hex dump of
that disk image, which is easier to inspect manually and also faster by
about 3 magnitudes.
Multiple arguments to atf_set are joined by spaces, there's no need for
an extra space.
The exit status on success must be 0, so don't ignore it.
Remove the unnecessary shell wrapper, as no redirection is going on.
Suggested by uwe@, in reaction to the previous commit, which preferred
octal in the examples. Hexadecimal escapes are more familiar to most
programmers, and the chance of mistaking \x14 for decimal 14 is less
than the chance of mistaking octal \014 for decimal 14.
This is an attempt to diagnose why it's flaky in the releng testbeds
but not when I run it. This change will be backed out once we get
new testbed output.
This is not very tidy at the moment, but it's an experiment using the
approach in PR bin/58112, to diagnose why t_sp:sigsafe keeps failing
intermittently. If this works, perhaps can tidy it up and apply it
to all the other tests that run rump_servers.
Otherwise, a pending signal may be delivered on the wrong stack when
we restore the signal mask.
While here:
- Tidy the code a little bit.
- Sprinkle comments to explain what's going on.
- Use forward branches for statically predicted not-taken.
=> val==0 is unlikely in longjmp
PR lib/57946
Otherwise, a pending signal may be delivered on the wrong stack when
we restore the signal mask.
While here:
- Tidy the code a little bit.
- Sprinkle comments to explain what's going on.
- Use `xorl %eXX,%eXX' instead of `xorq %rXX,%rXX'.
=> Same effect, one byte shorter, breaks dep chain on more uarches.
- Use forward branches for statically predicted not-taken.
=> val==0 is unlikely in longjmp
PR lib/57946
1. For tools that use elftoolchain: always use elftoolchain's
elfdefinitions.h. Don't even think about looking at the host's
sys/exec_elf.h, which makes no sense and should never happen.
(ELF tools that don't use elftoolchain, like m68k-elf2coff,
continue to use nbincludes/sys/exec_elf.h. But no more nbincludes
hacks in elftoolchain.)
2. For kernel components (solaris, zfs, dtrace): always use
sys/exec_elf.h, even in Solaris components via sys/elf.h.
elfdefinitions.h is not wired up in the kernel build at all.
3. For most userland components that involve libelf: use
elfdefinitions.h via libelf header files (libelf.h, gelf.h).
libdtrace in particular requires _all_ R_* reloc type definitions,
but sys/exec_elf.h brings in only the _current machine's_ R_*
reloc type definitions. (While here: Use uintptr_t instead of
Elf_Addr for pointer-to-integer cast, since Elf_Addr is MD and
provided only by sys/exec_elf.h, not by elfdefinitions.h.)
And most userland components using libelf don't rely on any
properties of the current machine from sys/exec_elf.h, so they can
use libelf's elfdefinition.h.
Exceptions:
- dtrace drti.c relies on link.h -> link_elf.h -> sys/exec_elf.h,
but it also relies on sys/dtrace.h -> sys/elf.h ->
elfdefinitions.h like other userland components using sys/elf.h.
- kdump-ioctl.c uses sys/exec_elf.h directly and sys/dtrace.h ->
sys/elf.h -> elfdefinitions like other userland components using
sys/elf.h.
- t_ptrace_wait.c (via t_ptrace_core_wait.h) uses libelf to parse
core files, but relies on sys/exec_elf.h for struct
netbsd_elfcore_procinfo.
None of these exceptions needs all R_* reloc type definitions, so
as a workaround, we can just suppress libelf's elfdefinitions.h by
defining _SYS_ELFDEFINITIONS_H_ and use sys/exec_elf.h in these
exceptions.
And undo the whole BUILTIN_ELF_HEADERS mistake. This was:
- half bogus workarounds for missing build_install dependencies in
tools/Makefile, which are no longer missing now, and
- half futile attempt to use src/sys/sys/exec_elf.h via nbincludes in
tools involving libelf instead of libelf's elfdefinitions.h, which
collides.
Longer-term, we may wish to unify sys/exec_elf.h and libelf's
elfdefinitions.h, so we don't have to play these games.
But at least now the games are limited to three .c files (one of
which is generated by Makefile.ioctl-c), rather than haphazardly
applied tree-wide by monstrous kludges in widely used .h files with
broken hackarounds to get the tools build lurching to completion.
The C standards do not specify a fixed type for an array subscript, it
just has to be an integer type. Previously, query 4 fired for the
ubiquitous expression 'ptr[sz]' when sz had type 'size_t'.
The test platform_ilp32_long is unaffected by this change, as the
integer constant 0x80000000 has type 'unsigned int', while size_t is
'unsigned long' on those platforms, and even though the types 'unsigned
int' and 'unsigned long' have the same value space, there's still a
conversion, at least for now.
rillig