svn commit: r293903 - in head/sys/boot: arm/uboot efi/fdt efi/libefi
Steven Hartland
steven at multiplay.co.uk
Thu Jan 14 09:46:16 UTC 2016
On 14/01/2016 09:27, NGie Cooper wrote:
>> On Jan 14, 2016, at 01:22, Steven Hartland <smh at FreeBSD.org> wrote:
>>
>> Author: smh
>> Date: Thu Jan 14 09:22:01 2016
>> New Revision: 293903
>> URL: https://svnweb.freebsd.org/changeset/base/293903
>>
>> Log:
>> Fix GCC warnings causing build failure after r293724
>>
>> Disable some compiler warnings for GCC (non-standard compiler) fixing
>> build failures introduced by r293724, which enabled WARNS in the EFI boot
>> code, when compiling with none standard compiler (GCC).
> Disabling warnings is wrong. Here’s how arm could be fixed:
>
> $ svn diff sys/boot/
> Index: sys/boot/common/bootstrap.h
> ===================================================================
> --- sys/boot/common/bootstrap.h (revision 293877)
> +++ sys/boot/common/bootstrap.h (working copy)
> @@ -32,6 +32,7 @@
> #include <sys/types.h>
> #include <sys/queue.h>
> #include <sys/linker_set.h>
> +#include <time.h>
>
> /*
> * Generic device specifier; architecture-dependant
> @@ -332,12 +333,8 @@
> extern struct arch_switch archsw;
>
> /* This must be provided by the MD code, but should it be in the archsw? */
> -void delay(int delay);
> -
> void dev_cleanup(void);
>
> -time_t time(time_t *tloc);
> -
> #ifndef CTASSERT /* Allow lint to override */
> #define CTASSERT(x) _CTASSERT(x, __LINE__)
> #define _CTASSERT(x, y) __CTASSERT(x, y)
> Index: sys/boot/efi/include/efiapi.h
> ===================================================================
> --- sys/boot/efi/include/efiapi.h (revision 293877)
> +++ sys/boot/efi/include/efiapi.h (working copy)
> @@ -532,6 +532,7 @@
> typedef
> EFI_STATUS
> (EFIAPI *EFI_RESERVED_SERVICE) (
> + VOID
> );
>
> typedef
>
> amd64 is a bit trickier:
>
> /scratch/tmp/ngie/svn/sys/boot/efi/libefi/../include/efigop.h:75: warning: 'ms_abi' attribute directive ignored
>
> I didn’t dig into why this is happening [yet], other than there maybe being MS extensions involved?
>
Thanks for that Garret, as Ian confirmed this change fixed his immediate
issue I went with it, after confirming with a full GCC tinderbox of course.
I agree your changes are more correct, however I don't have an build
resource ATM, so if you have time / resources to confirm they work
correctly with a full CLANG and GCC tinderbox please feel LMK and I'll
get it committed :)
If you don't get chance before the end of the week, I'll have build
resource available and will look to test then, hope this is OK?
Regards
Steve
More information about the svn-src-head
mailing list