3:27 p.m.
During the past couple of weeks I've updated my build chain to use gcc 9.1
which generates some additional warnings that cause the build to fail
when building with -Werror.
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk>
Mark Cave-Ayland (2):
all: gcc 9 build fixes
ppc: reduce size of Forth dictionary to 384K
arch/ppc/qemu/kernel.c | 4 ++--
arch/sparc32/context.c | 2 +-
drivers/cuda.c | 4 ++--
drivers/ide.c | 2 +-
drivers/pmu.c | 4 ++--
fs/hfs/hfs_fs.c | 2 +-
packages/nvram.c | 2 +-
7 files changed, 10 insertions(+), 10 deletions(-)
--
2.20.1
3:27 p.m.
New subject: [PATCH 1/2] all: gcc 9 build fixes
Fix up warnings generated by building with -Werror under gcc 9.
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk>
---
arch/sparc32/context.c | 2 +-
drivers/cuda.c | 4 ++--
drivers/ide.c | 2 +-
drivers/pmu.c | 4 ++--
fs/hfs/hfs_fs.c | 2 +-
packages/nvram.c | 2 +-
6 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/sparc32/context.c b/arch/sparc32/context.c
index 65c421a..b4b0ae3 100644
--- a/arch/sparc32/context.c
+++ b/arch/sparc32/context.c
@@ -115,7 +115,7 @@ struct context *switch_to(struct context *ctx)
__context = ctx;
asm __volatile__ ("\n\tcall __switch_context"
"\n\tnop" ::: "g1", "g2",
"g3", "g4", "g5", "g6", "g7",
- "o0", "o1", "o2", "o3",
"o4", "o5", "sp", "o7",
+ "o0", "o1", "o2", "o3",
"o4", "o5", "o7",
"l0", "l1", "l2", "l3",
"l4", "l5", "l6", "l7",
"i0", "i1", "i2", "i3",
"i4", "i5", "i7",
"f0", "f1", "f2", "f3",
"f4", "f5", "f6", "f7", "f8",
"f9",
diff --git a/drivers/cuda.c b/drivers/cuda.c
index ff5d22d..d079d1e 100644
--- a/drivers/cuda.c
+++ b/drivers/cuda.c
@@ -369,7 +369,7 @@ static void
rtc_init(char *path)
{
phandle_t ph, aliases;
- char buf[64];
+ char buf[128];
snprintf(buf, sizeof(buf), "%s/rtc", path);
REGISTER_NAMED_NODE(rtc, buf);
@@ -387,7 +387,7 @@ static void
powermgt_init(char *path)
{
phandle_t ph;
- char buf[64];
+ char buf[128];
snprintf(buf, sizeof(buf), "%s/power-mgt", path);
REGISTER_NAMED_NODE(rtc, buf);
diff --git a/drivers/ide.c b/drivers/ide.c
index edbd287..519ad46 100644
--- a/drivers/ide.c
+++ b/drivers/ide.c
@@ -987,7 +987,7 @@ ob_ide_identify_drive(struct ide_drive *drive)
drive->sect = id.sectors;
}
- strncpy(drive->model, (char*)id.model, sizeof(id.model));
+ strncpy(drive->model, (char*)id.model, sizeof(drive->model));
drive->model[40] = '\0';
return 0;
}
diff --git a/drivers/pmu.c b/drivers/pmu.c
index 6fc5363..9198846 100644
--- a/drivers/pmu.c
+++ b/drivers/pmu.c
@@ -523,7 +523,7 @@ NODE_METHODS(rtc) = {
static void rtc_init(char *path)
{
phandle_t ph, aliases;
- char buf[64];
+ char buf[128];
snprintf(buf, sizeof(buf), "%s/rtc", path);
REGISTER_NAMED_NODE(rtc, buf);
@@ -540,7 +540,7 @@ static void rtc_init(char *path)
static void powermgt_init(char *path)
{
phandle_t ph;
- char buf[64];
+ char buf[128];
/* This is a bunch of magic "Feature" bits for which we only have
* partial definitions from Darwin. These are taken from a
diff --git a/fs/hfs/hfs_fs.c b/fs/hfs/hfs_fs.c
index 2e63dbf..ca8a433 100644
--- a/fs/hfs/hfs_fs.c
+++ b/fs/hfs/hfs_fs.c
@@ -86,7 +86,7 @@ _search( hfsvol *vol, const char *path, const char *sname, hfsfile
**ret_fd )
strncpy( buf, path, sizeof(buf) );
if( buf[strlen(buf)-1] != ':' )
- strncat( buf, ":", sizeof(buf) );
+ strncat( buf, ":", sizeof(buf) - 1 );
buf[sizeof(buf)-1] = 0;
p = buf + strlen( buf );
diff --git a/packages/nvram.c b/packages/nvram.c
index 3182edf..e895fed 100644
--- a/packages/nvram.c
+++ b/packages/nvram.c
@@ -105,7 +105,7 @@ create_free_part( char *ptr, int size )
nvpart_t *nvp = (nvpart_t*)ptr;
memset( nvp, 0, size );
- strncpy( nvp->name, "777777777777", sizeof(nvp->name) );
+ strncpy( nvp->name, "77777777777", sizeof(nvp->name) );
nvp->signature = NV_SIG_FREE;
nvp->len_hi = (size /16) >> 8;
nvp->len_lo = size /16;
--
2.20.1
3:27 p.m.
New subject: [PATCH 2/2] ppc: reduce size of Forth dictionary to 384K
gcc 9 emits a fatal error when building OpenBIOS for ppc because the size of the
generated image is greater than the available ROM area when building with -O0.
Reduce the size of the Forth dictionary from 512K to 384K to allow sufficient
space for generating OpenBIOS images suitable for debugging.
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk>
---
arch/ppc/qemu/kernel.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/ppc/qemu/kernel.c b/arch/ppc/qemu/kernel.c
index b26fba5..893ab68 100644
--- a/arch/ppc/qemu/kernel.c
+++ b/arch/ppc/qemu/kernel.c
@@ -26,8 +26,8 @@
#include "kernel.h"
#define MEMORY_SIZE (256*1024) /* 256K ram for hosted system */
-/* 512K for the dictionary */
-#define DICTIONARY_SIZE (512 * 1024 / sizeof(ucell))
+/* 384K for the dictionary */
+#define DICTIONARY_SIZE (384 * 1024 / sizeof(ucell))
#ifdef __powerpc64__
#define DICTIONARY_BASE 0xfff08000 /* this must match the value in ldscript! */
#define DICTIONARY_SECTION __attribute__((section(".data.dict")))
--
2.20.1
3:41 a.m.
On 16/08/2019 08:27, Mark Cave-Ayland wrote:
During the past couple of weeks I've updated my
build chain to use gcc 9.1
which generates some additional warnings that cause the build to fail
when building with -Werror.
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk>
Mark Cave-Ayland (2):
all: gcc 9 build fixes
ppc: reduce size of Forth dictionary to 384K
arch/ppc/qemu/kernel.c | 4 ++--
arch/sparc32/context.c | 2 +-
drivers/cuda.c | 4 ++--
drivers/ide.c | 2 +-
drivers/pmu.c | 4 ++--
fs/hfs/hfs_fs.c | 2 +-
packages/nvram.c | 2 +-
7 files changed, 10 insertions(+), 10 deletions(-)
I've pushed this to master since it conflicts with the latest version of the
active-device patchset which I'm about to resend.
ATB,
Mark.
5:09 a.m.
On Aug 18, 2019, at 3:41 PM, Mark Cave-Ayland
<mark.cave-ayland(a)ilande.co.uk> wrote:
On 16/08/2019 08:27, Mark Cave-Ayland wrote:
> During the past couple of weeks I've updated my build chain to use gcc 9.1
> which generates some additional warnings that cause the build to fail
> when building with -Werror.
I'm thinking removing -Werror might be a better option.
5:30 a.m.
On 18/08/2019 22:09, Programmingkid wrote:
Why? All of these things flagged up by the compiler are genuine errors.
ATB,
Mark.
On Aug 18,
2019, at 3:41 PM, Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> wrote:
On 16/08/2019 08:27, Mark Cave-Ayland wrote:
> During the past couple of weeks I've updated my build chain to use gcc 9.1
> which generates some additional warnings that cause the build to fail
> when building with -Werror.
I'm thinking removing -Werror might be a better option.
9:24 a.m.
On Aug 18, 2019, at 5:30 PM, Mark Cave-Ayland
<mark.cave-ayland(a)ilande.co.uk> wrote:
On 18/08/2019 22:09, Programmingkid wrote:
Why? All of these things flagged up by the compiler are genuine errors.
ATB,
Mark.
The -Werror option treats warnings as errors. I would not consider a warning to be a
genuine error. I always remove -Werror in order for OpenBIOS to compile on my system. So
far this works well.
On Aug
18, 2019, at 3:41 PM, Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> wrote:
On 16/08/2019 08:27, Mark Cave-Ayland wrote:
> During the past couple of weeks I've updated my build chain to use gcc 9.1
> which generates some additional warnings that cause the build to fail
> when building with -Werror.
I'm thinking removing -Werror might be a better option. 
6:13 p.m.
On Sun, 18 Aug 2019, Programmingkid wrote:
These warnings often mean that there may be a problem or at least the code
is not completely obvious just the compiler is not sure if it's really an
error or could not exactly identify it and it might work but needs review.
That's what warning means so definitely not to be ignored. It's a good
idea to write code that compiles without warnings and is correct without
any doubt which -Werror ensures. (Especially for portable code. Warnings
are only acceptable if you need to do something very tricky and you know
it will work but it's rarely the case that's needed.) If it compiles and
works with warnings you're lucky but that does not mean the code cannot be
improved. If you need removing -Werror to compile with your compiler maybe
a better way is to report those problems so they can be fixed (maybe they
are actual bugs that gcc did not notice so far) rather than removing
-Werror and ignoring potential problems.
Regards,
BALATON Zoltan
On Aug 18,
2019, at 5:30 PM, Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> wrote:
On 18/08/2019 22:09, Programmingkid wrote:
The -Werror option treats warnings as errors. I would not consider a
warning to be a genuine error. I always remove -Werror in order for
OpenBIOS to compile on my system. So far this works well. I'm thinking removing -Werror might be a
better option.
Why? All of these things flagged up by the compiler are genuine errors.
ATB,
Mark. 
8:15 p.m.
On Mon, Aug 19, 2019 at 12:13:42PM +0200, BALATON Zoltan wrote:
On Sun, 18 Aug 2019, Programmingkid wrote:
No, it usually ensures your code does not compile, instead.
The -Werror option treats warnings as errors. I
would not consider a
warning to be a genuine error. I always remove -Werror in order for
OpenBIOS to compile on my system. So far this works well.
These warnings often mean that there may be a problem or at least the code
is not completely obvious just the compiler is not sure if it's really an
error or could not exactly identify it and it might work but needs review.
That's what warning means so definitely not to be ignored. It's a good
idea to write code that compiles without warnings and is correct without
any doubt which -Werror ensures. (Especially for portable code. Warnings
are only acceptable if you need to do something very tricky and you know
it will work but it's rarely the case that's needed.) If it compiles and
works with warnings you're lucky but that does not mean the code cannot be
improved. If you need removing -Werror to compile with your compiler maybe
a better way is to report those problems so they can be fixed (maybe they
are actual bugs that gcc did not notice so far) rather than removing
-Werror and ignoring potential problems.
And shipping with -Werror enabled is a disservice to your users.
Users have a different environment than you tested with -- compiler
version, etc.
Segher
281
days inactive
284
days old
8 comments
4 participants
participants (4)
-
BALATON Zoltan -
Mark Cave-Ayland -
Programmingkid -
Segher Boessenkool