| Age | Commit message (Collapse) | Author |
|---|
|
cov-analysis-linux64-2020.09 is a lot more successful than the older
versions at building, but it still has some... issues. Among them, it
is of the belief that this:
void
foo(char *fmt, ...)
{
__builtin_va_list ap;
__builtin_ms_va_start(ap, fmt); /* <- here */
...
}
is an uninitialized use of "ap".
This patch adds defined(__COVERITY__) to the list of criteria for using
sysv va lists, which it has no such confusion about.
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
Don't check SHIM_UNIT_TEST.
This fixes conflicting declarations for __builtin_ms_va_list on amd64:
In file included from shim.h:47,
from test.c:10:
../include/system/stdarg.h:30:27: error: conflicting types for '__builtin_ms_va_list'
typedef __builtin_va_list __builtin_ms_va_list;
^~~~~~~~~~~~~~~~~~~~
cc1: note: previous declaration of '__builtin_ms_va_list' was here
In file included from shim.h:47,
from test-csv.c:9:
../include/system/stdarg.h:30:27: error: conflicting types for '__builtin_ms_va_list'
typedef __builtin_va_list __builtin_ms_va_list;
^~~~~~~~~~~~~~~~~~~~
cc1: note: previous declaration of '__builtin_ms_va_list' was here
In file included from shim.h:47,
from csv.c:6:
../include/system/stdarg.h:30:27: error: conflicting types for '__builtin_ms_va_list'
typedef __builtin_va_list __builtin_ms_va_list;
^~~~~~~~~~~~~~~~~~~~
cc1: note: previous declaration of '__builtin_ms_va_list' was here
Signed-off-by: Steve McIntyre <93sam@debian.org>
|
|
For some reason when we try to ever use the builtins, even with the
symbol there as a fallback, something goes horribly wrong somewhere
around here:
| (gdb) bt
| #0 strcmp (s1=0x7d492359 "MD5", s2=0x7d492359 "MD5") at include/system/string.h:57
| #1 0x000000007d460419 in getrn (lh=lh@entry=0x7e081318, data=data@entry=0x7e084398, rhash=rhash@entry=0x7f7c9268) at crypto/lhash/lhash.c:415
| #2 0x000000007d46076e in lh_insert (lh=0x7e081318, data=data@entry=0x7e084398) at crypto/lhash/lhash.c:188
| #3 0x000000007d43e027 in OBJ_NAME_add (name=name@entry=0x7d492359 "MD5", type=type@entry=1, data=data@entry=0x7d4ad3a0 <md5_md> "\004") at crypto/objects/o_names.c:202
As much as I love a Sisyphean challenge, in the interest of not having
bugs or time, this patch changes it to just not use them for anything
other than guaranteeing our implementations have the exact same types as
you would expect.
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
Be much more explicit about exactly which va_* stuff comes from which
ABI in both shim and gnu-efi. This fixes the problem where we see:
| (null):0:(null)() v->name:"(null)" v->rtname:"(null)"
| (null):0:(null)() v->data_size:0 v->data:0x0
and similar messages where everything is NULL.
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
Signed-off-by: Alex Burmashev <alexander.burmashev@oracle.com>
|
|
Note the one test case I'm not 100% sure about. Someone let me know.
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
This gets us the same working definition for VA_* va_* etc everywhere,
and it's the same definition edk2 is using.
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
This re-structures our includes so we can be sure everything is always
including all the system headers in a uniform, predictable way.
Temporarily it also adds a bunch of junk at all the places we use
variadic functions to specifically pick either the MS (cdecl) or ELF
ABIs.
I'm not 100% sure that's all correct (see later patch) but it's enough
to allow this to build.
Signed-off-by: Peter Jones <pjones@redhat.com>
|
