Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Upstream a local patch from rawhide #177

Merged
merged 1 commit into from
Oct 1, 2021

Conversation

frozencemetery
Copy link
Member

@frozencemetery frozencemetery commented Sep 2, 2021

Currently, we carry this fix downstream:

Fix abidw output for missing variadic arguments

GCC forgets to add the varidic arguments into debugging data if the
compilation unit is built with -flto option. As a result, the prebuilt
XML ABI dumps were missing the last argument at 4 functions (e.g.
efi_error_set()).

This was unnoticed until Fedora enabled LTO globally and had to
disable LTO in efivar explicitly because efivar uses symbol versioning
with top-level assembler statements which is not compatible with LTO.

Since then the abicheck failed:

make[2]: Leaving directory '/builddir/build/BUILD/efivar-37/src'
abidiff \
 --suppr abignore \
 --headers-dir2 /builddir/build/BUILD/efivar-37/src/include/efivar/ \
 libefivar.abixml \
 libefivar.so
Functions changes summary: 0 Removed, 2 Changed (8 filtered out), 0 Added functions
Variables changes summary: 0 Removed, 0 Changed, 0 Added variable
2 functions with some indirect sub-type change:
  [C]'function int _efi_set_variable_variadic(efi_guid_t, const char*, uint8_t*, size_t, uint32_t)' at lib.c:44:1 has some indirect sub-type changes:
    parameter 6 of type '...' was added
  [C]'function int efi_error_set(const char*, const char*, int, int, const char*)' at error.c:86:1 has some indirect sub-type changes:
    parameter 6 of type '...' was added
make[1]: *** [/builddir/build/BUILD/efivar-37/src/include/rules.mk:41: libefivar.abicheck] Error 4
make[1]: Leaving directory '/builddir/build/BUILD/efivar-37/src'

This patch corrects the pregenerated abixml files that were probably
generated with the faulty GCC.

<https://bugzilla.redhat.com/show_bug.cgi?id=1863475>
<https://bugzilla.redhat.com/show_bug.cgi?id=1891787>

Signed-off-by: Petr Písař <ppisar@redhat.com>

GCC forgets to add the varidic arguments into debugging data if the
compilation unit is built with -flto option. As a result, the prebuilt
XML ABI dumps were missing the last argument at 4 functions (e.g.
efi_error_set()).

This was unnoticed until Fedora enabled LTO globally and had to
disable LTO in efivar explicitly because efivar uses symbol versioning
with top-level assembler statements which is not compatible with LTO.

Since then the abicheck failed:

make[2]: Leaving directory '/builddir/build/BUILD/efivar-37/src'
abidiff \
 --suppr abignore \
 --headers-dir2 /builddir/build/BUILD/efivar-37/src/include/efivar/ \
 libefivar.abixml \
 libefivar.so
Functions changes summary: 0 Removed, 2 Changed (8 filtered out), 0 Added functions
Variables changes summary: 0 Removed, 0 Changed, 0 Added variable
2 functions with some indirect sub-type change:
  [C]'function int _efi_set_variable_variadic(efi_guid_t, const char*, uint8_t*, size_t, uint32_t)' at lib.c:44:1 has some indirect sub-type changes:
    parameter 6 of type '...' was added
  [C]'function int efi_error_set(const char*, const char*, int, int, const char*)' at error.c:86:1 has some indirect sub-type changes:
    parameter 6 of type '...' was added
make[1]: *** [/builddir/build/BUILD/efivar-37/src/include/rules.mk:41: libefivar.abicheck] Error 4
make[1]: Leaving directory '/builddir/build/BUILD/efivar-37/src'

This patch corrects the pregenerated abixml files that were probably
generated with the faulty GCC.

<https://bugzilla.redhat.com/show_bug.cgi?id=1863475>
<https://bugzilla.redhat.com/show_bug.cgi?id=1891787>

Signed-off-by: Petr Písař <ppisar@redhat.com>
@vathpela vathpela merged commit a48e007 into rhboot:master Oct 1, 2021
@vathpela
Copy link
Contributor

vathpela commented Oct 1, 2021

I've pulled this, not so much because it's necessarily useful as is - when we regenerate for the newest ABI it'll inevitably be wrong again unless gcc is fixed - but so we can find it easily for reference later.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants