11:44 p.m.
Without the patch, the following gcc-11 compilation warnings are
emitted for filesys.c:
filesys.c: In function 'mount_point':
filesys.c:718:17: warning: 'pclose' called on pointer returned from a mismatched
allocation function [-Wmismatched-dealloc]
718 | pclose(mp);
| ^~~~~~~~~~
filesys.c:709:27: note: returned from 'fopen'
709 | if ((mp = fopen(mntfile, "r")) == NULL)
| ^~~~~~~~~~~~~~~~~~~
filesys.c:738:17: warning: 'pclose' called on pointer returned from a mismatched
allocation function [-Wmismatched-dealloc]
738 | pclose(mp);
| ^~~~~~~~~~
filesys.c:723:27: note: returned from 'fopen'
723 | if ((mp = fopen(mntfile, "r")) == NULL)
| ^~~~~~~~~~~~~~~~~~~
Signed-off-by: Kazuhito Hagio <k-hagio-ab(a)nec.com>
---
filesys.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/filesys.c b/filesys.c
index 43cbe82..a863f04 100644
--- a/filesys.c
+++ b/filesys.c
@@ -715,7 +715,7 @@ mount_point(char *name)
continue;
found++;
}
- pclose(mp);
+ fclose(mp);
if (!(mount_points = (char **)malloc(sizeof(char *) * found)))
return FALSE;
@@ -735,7 +735,7 @@ mount_point(char *name)
mount_points_gathered++, i++;
}
}
- pclose(mp);
+ fclose(mp);
if (CRASHDEBUG(2))
for (i = 0; i < mount_points_gathered; i++)
--
2.31.1
11:44 p.m.
New subject: [PATCH 3/4] Fix gcc-11 compilation warning on makedumpfile.c
Without the patch, the following gcc-11 compilation warning is emitted
for makedumpfile.c:
In function 'flattened_format_get_osrelease',
inlined from 'check_flattened_format' at makedumpfile.c:236:3:
makedumpfile.c:392:9: warning: 'fclose' called on pointer returned from a
mismatched allocation function [-Wmismatched-dealloc]
392 | fclose(pipe);
| ^~~~~~~~~~~~
makedumpfile.c: In function 'check_flattened_format':
makedumpfile.c:380:21: note: returned from 'popen'
380 | if ((pipe = popen(buf, "r")) == NULL)
| ^~~~~~~~~~~~~~~
Signed-off-by: Kazuhito Hagio <k-hagio-ab(a)nec.com>
---
makedumpfile.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/makedumpfile.c b/makedumpfile.c
index ebf24f5..26d12b6 100644
--- a/makedumpfile.c
+++ b/makedumpfile.c
@@ -389,5 +389,5 @@ flattened_format_get_osrelease(char *file)
}
}
- fclose(pipe);
+ pclose(pipe);
}
--
2.31.1
11:44 p.m.
New subject: [PATCH 4/4] Fix gcc-11 compilation warning on kvmdump.c
Without the patch, the following gcc-11 compilation warning is emitted
for kvmdump.c:
In function 'write_mapfile_registers',
inlined from 'write_mapfile_trailer' at kvmdump.c:947:3,
inlined from 'kvmdump_init' at kvmdump.c:145:4:
kvmdump.c:972:13: warning: 'write' reading 8 bytes from a region of size 4
[-Wstringop-overread]
972 | if (write(kvm->mapfd, &kvm->cpu_devices, sizeof(uint64_t)) !=
sizeof(uint64_t))
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from kvmdump.c:19:
kvmdump.c: In function 'kvmdump_init':
kvmdump.h:67:18: note: source object 'cpu_devices' of size 4
67 | uint32_t cpu_devices;
| ^~~~~~~~~~~
In file included from defs.h:26,
from kvmdump.c:18:
/usr/include/unistd.h:378:16: note: in a call to function 'write' declared with
attribute 'access (read_only, 2, 3)'
378 | extern ssize_t write (int __fd, const void *__buf, size_t __n) __wur
| ^~~~~
Signed-off-by: Kazuhito Hagio <k-hagio-ab(a)nec.com>
---
kvmdump.c | 2 +-
kvmdump.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/kvmdump.c b/kvmdump.c
index 4db96bd..e515bf0 100644
--- a/kvmdump.c
+++ b/kvmdump.c
@@ -297,7 +297,7 @@ kvmdump_memory_dump(FILE *ofp)
(ulonglong)kvm->page_cache[i].paddr);
}
- fprintf(ofp, " cpu_devices: %d\n", kvm->cpu_devices);
+ fprintf(ofp, " cpu_devices: %ld\n", kvm->cpu_devices);
fprintf(ofp, " iohole: %llx (%llx - %llx)\n",
(ulonglong)kvm->iohole, 0x100000000ULL - kvm->iohole,
0x100000000ULL);
diff --git a/kvmdump.h b/kvmdump.h
index 07e047b..2e408ae 100644
--- a/kvmdump.h
+++ b/kvmdump.h
@@ -64,7 +64,7 @@ struct kvmdump_data {
ulong compresses;
uint64_t kvbase;
ulong *debug;
- uint32_t cpu_devices;
+ uint64_t cpu_devices;
struct register_set *registers;
uint64_t iohole;
};
--
2.31.1
11:44 p.m.
New subject: [PATCH 2/4] Fix gcc-11 compilation warning on symbols.c
Without the patch, the following gcc-11 compliation warning is emitted
for symbols.c:
symbols.c: In function 'cmd_p':
symbols.c:7412:38: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]
7412 | *(cpuspec-1) = ':';
| ~~~~~~~~~~~~~^~~~~
Signed-off-by: Kazuhito Hagio <k-hagio-ab(a)nec.com>
---
symbols.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/symbols.c b/symbols.c
index bee1faf..42c4eb4 100644
--- a/symbols.c
+++ b/symbols.c
@@ -7351,7 +7351,7 @@ cmd_p(void)
unsigned radix;
int do_load_module_filter;
char buf1[BUFSIZE];
- char *cpuspec;
+ char *cpuspec, *p;
do_load_module_filter = radix = 0;
@@ -7386,7 +7386,7 @@ cmd_p(void)
if (argerrs || !args[optind])
cmd_usage(pc->curcmd, SYNOPSIS);
- cpuspec = strrchr(args[optind], ':');
+ p = cpuspec = strrchr(args[optind], ':');
if (cpuspec)
*cpuspec++ = NULLCHAR;
@@ -7409,7 +7409,7 @@ cmd_p(void)
sp->name);
else
/* maybe a valid C expression (e.g. ':') */
- *(cpuspec-1) = ':';
+ *p = ':';
}
process_gdb_output(concat_args(buf1, 0, TRUE), radix,
--
2.31.1
1:30 a.m.
New subject: [PATCH 2/4] Fix gcc-11 compilation warning on symbols.c
Hi, Kazu
Thank you for the fix.
On Fri, Jul 22, 2022 at 12:45 PM HAGIO KAZUHITO(萩尾 一仁) <k-hagio-ab(a)nec.com>
wrote:
Without the patch, the following gcc-11 compliation warning is
emitted
for symbols.c:
symbols.c: In function 'cmd_p':
symbols.c:7412:38: warning: writing 1 byte into a region of size 0
[-Wstringop-overflow=]
7412 | *(cpuspec-1) = ':';
| ~~~~~~~~~~~~~^~~~~
I have one question about it:
This issue only appears in gcc-11 and earlier, I tested it with gcc-12, but
it disappeared. It's interesting.
In addition, a new warning was found(gcc-12), but it is not related to this
patch.
...
gcc -c -g -DX86_64 -DLZO -DGDB_10_2 -g -O2 lkcd_v1.c -DMCLX -Wall -O2
-Wstrict-prototypes -Wmissing-prototypes -fstack-protector -Wformat-security
lkcd_v1.c: In function ‘dump_lkcd_environment_v1’:
lkcd_v1.c:252:20: warning: the comparison will always evaluate as ‘true’
for the address of ‘dh_panic_string’ will never be NULL [-Waddress]
252 | dh && dh->dh_panic_string &&
| ^~
In file included from lkcd_v1.c:21:
lkcd_vmdump_v1.h:108:30: note: ‘dh_panic_string’ declared here
108 | char dh_panic_string[DUMP_PANIC_LEN];
| ^~~~~~~~~~~~~~~
gcc -c -g -DX86_64 -DLZO -DGDB_10_2 -g -O2 lkcd_v2_v3.c -DMCLX -Wall -O2
-Wstrict-prototypes -Wmissing-prototypes -fstack-protector -Wformat-security
lkcd_v2_v3.c: In function ‘dump_lkcd_environment_v2_v3’:
lkcd_v2_v3.c:310:20: warning: the comparison will always evaluate as ‘true’
for the address of ‘dh_panic_string’ will never be NULL [-Waddress]
310 | dh && dh->dh_panic_string &&
| ^~
In file included from lkcd_v2_v3.c:21:
lkcd_vmdump_v2_v3.h:205:30: note: ‘dh_panic_string’ declared here
205 | char dh_panic_string[DUMP_PANIC_LEN];
| ^~~~~~~~~~~~~~~
gcc -c -g -DX86_64 -DLZO -DGDB_10_2 -g -O2 lkcd_v5.c -DMCLX -Wall -O2
-Wstrict-prototypes -Wmissing-prototypes -fstack-protector -Wformat-security
lkcd_v5.c: In function ‘dump_lkcd_environment_v5’:
lkcd_v5.c:273:20: warning: the comparison will always evaluate as ‘true’
for the address of ‘dh_panic_string’ will never be NULL [-Waddress]
273 | dh && dh->dh_panic_string &&
| ^~
In file included from lkcd_v5.c:20:
lkcd_dump_v5.h:163:30: note: ‘dh_panic_string’ declared here
163 | char dh_panic_string[DUMP_PANIC_LEN];
| ^~~~~~~~~~~~~~~
gcc -c -g -DX86_64 -DLZO -DGDB_10_2 -g -O2 lkcd_v7.c -DMCLX -Wall -O2
-Wstrict-prototypes -Wmissing-prototypes -fstack-protector -Wformat-security
lkcd_v7.c: In function ‘dump_lkcd_environment_v7’:
lkcd_v7.c:350:20: warning: the comparison will always evaluate as ‘true’
for the address of ‘dh_panic_string’ will never be NULL [-Waddress]
350 | dh && dh->dh_panic_string &&
| ^~
In file included from lkcd_v7.c:21:
lkcd_dump_v5.h:163:30: note: ‘dh_panic_string’ declared here
163 | char dh_panic_string[DUMP_PANIC_LEN];
| ^~~~~~~~~~~~~~~
gcc -c -g -DX86_64 -DLZO -DGDB_10_2 -g -O2 lkcd_v8.c -DMCLX -Wall -O2
-Wstrict-prototypes -Wmissing-prototypes -fstack-protector -Wformat-security
lkcd_v8.c: In function ‘dump_lkcd_environment_v8’:
lkcd_v8.c:546:20: warning: the comparison will always evaluate as ‘true’
for the address of ‘dh_panic_string’ will never be NULL [-Waddress]
546 | dh && dh->dh_panic_string &&
| ^~
In file included from lkcd_v8.c:23:
lkcd_dump_v8.h:165:30: note: ‘dh_panic_string’ declared here
165 | char dh_panic_string[DUMP_PANIC_LEN];
...
Thanks.
Lianbo
Signed-off-by: Kazuhito Hagio <k-hagio-ab(a)nec.com>
---
symbols.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/symbols.c b/symbols.c
index bee1faf..42c4eb4 100644
--- a/symbols.c
+++ b/symbols.c
@@ -7351,7 +7351,7 @@ cmd_p(void)
unsigned radix;
int do_load_module_filter;
char buf1[BUFSIZE];
- char *cpuspec;
+ char *cpuspec, *p;
do_load_module_filter = radix = 0;
@@ -7386,7 +7386,7 @@ cmd_p(void)
if (argerrs || !args[optind])
cmd_usage(pc->curcmd, SYNOPSIS);
- cpuspec = strrchr(args[optind], ':');
+ p = cpuspec = strrchr(args[optind], ':');
if (cpuspec)
*cpuspec++ = NULLCHAR;
@@ -7409,7 +7409,7 @@ cmd_p(void)
sp->name);
else
/* maybe a valid C expression (e.g. ':') */
- *(cpuspec-1) = ':';
+ *p = ':';
}
process_gdb_output(concat_args(buf1, 0, TRUE), radix,
--
2.31.1
11:21 p.m.
New subject: [PATCH 2/4] Fix gcc-11 compilation warning on symbols.c
Hi Lianbo,
thanks for the review.
On 2022/07/25 15:30, lijiang wrote:
Hi, Kazu
Thank you for the fix.
On Fri, Jul 22, 2022 at 12:45 PM HAGIO KAZUHITO(萩尾 一仁) <k-hagio-ab(a)nec.com>
wrote:
> Without the patch, the following gcc-11 compliation warning is emitted
> for symbols.c:
>
> symbols.c: In function 'cmd_p':
> symbols.c:7412:38: warning: writing 1 byte into a region of size 0
> [-Wstringop-overflow=]
> 7412 | *(cpuspec-1) = ':';
> | ~~~~~~~~~~~~~^~~~~
>
I have one question about it:
This issue only appears in gcc-11 and earlier, I tested it with gcc-12, but
it disappeared. It's interesting.
I think that the warning is a false detection. This patch has no behavior
change, just a cosmetic change to avoid the warning. I'm not sure, but it
might be a gcc bug and fixed in gcc-12.
Thanks,
Kazu
>
> In addition, a new warning was found(gcc-12), but it is not related to this
> patch.
> ...
> gcc -c -g -DX86_64 -DLZO -DGDB_10_2 -g -O2 lkcd_v1.c -DMCLX -Wall -O2
> -Wstrict-prototypes -Wmissing-prototypes -fstack-protector -Wformat-security
> lkcd_v1.c: In function ‘dump_lkcd_environment_v1’:
> lkcd_v1.c:252:20: warning: the comparison will always evaluate as ‘true’
> for the address of ‘dh_panic_string’ will never be NULL [-Waddress]
> 252 | dh && dh->dh_panic_string &&
> | ^~
> In file included from lkcd_v1.c:21:
> lkcd_vmdump_v1.h:108:30: note: ‘dh_panic_string’ declared here
> 108 | char dh_panic_string[DUMP_PANIC_LEN];
> | ^~~~~~~~~~~~~~~
> gcc -c -g -DX86_64 -DLZO -DGDB_10_2 -g -O2 lkcd_v2_v3.c -DMCLX -Wall -O2
> -Wstrict-prototypes -Wmissing-prototypes -fstack-protector -Wformat-security
> lkcd_v2_v3.c: In function ‘dump_lkcd_environment_v2_v3’:
> lkcd_v2_v3.c:310:20: warning: the comparison will always evaluate as ‘true’
> for the address of ‘dh_panic_string’ will never be NULL [-Waddress]
> 310 | dh && dh->dh_panic_string &&
> | ^~
> In file included from lkcd_v2_v3.c:21:
> lkcd_vmdump_v2_v3.h:205:30: note: ‘dh_panic_string’ declared here
> 205 | char dh_panic_string[DUMP_PANIC_LEN];
> | ^~~~~~~~~~~~~~~
> gcc -c -g -DX86_64 -DLZO -DGDB_10_2 -g -O2 lkcd_v5.c -DMCLX -Wall -O2
> -Wstrict-prototypes -Wmissing-prototypes -fstack-protector -Wformat-security
> lkcd_v5.c: In function ‘dump_lkcd_environment_v5’:
> lkcd_v5.c:273:20: warning: the comparison will always evaluate as ‘true’
> for the address of ‘dh_panic_string’ will never be NULL [-Waddress]
> 273 | dh && dh->dh_panic_string &&
> | ^~
> In file included from lkcd_v5.c:20:
> lkcd_dump_v5.h:163:30: note: ‘dh_panic_string’ declared here
> 163 | char dh_panic_string[DUMP_PANIC_LEN];
> | ^~~~~~~~~~~~~~~
> gcc -c -g -DX86_64 -DLZO -DGDB_10_2 -g -O2 lkcd_v7.c -DMCLX -Wall -O2
> -Wstrict-prototypes -Wmissing-prototypes -fstack-protector -Wformat-security
> lkcd_v7.c: In function ‘dump_lkcd_environment_v7’:
> lkcd_v7.c:350:20: warning: the comparison will always evaluate as ‘true’
> for the address of ‘dh_panic_string’ will never be NULL [-Waddress]
> 350 | dh && dh->dh_panic_string &&
> | ^~
> In file included from lkcd_v7.c:21:
> lkcd_dump_v5.h:163:30: note: ‘dh_panic_string’ declared here
> 163 | char dh_panic_string[DUMP_PANIC_LEN];
> | ^~~~~~~~~~~~~~~
> gcc -c -g -DX86_64 -DLZO -DGDB_10_2 -g -O2 lkcd_v8.c -DMCLX -Wall -O2
> -Wstrict-prototypes -Wmissing-prototypes -fstack-protector -Wformat-security
> lkcd_v8.c: In function ‘dump_lkcd_environment_v8’:
> lkcd_v8.c:546:20: warning: the comparison will always evaluate as ‘true’
> for the address of ‘dh_panic_string’ will never be NULL [-Waddress]
> 546 | dh && dh->dh_panic_string &&
> | ^~
> In file included from lkcd_v8.c:23:
> lkcd_dump_v8.h:165:30: note: ‘dh_panic_string’ declared here
> 165 | char dh_panic_string[DUMP_PANIC_LEN];
> ...
>
> Thanks.
> Lianbo
>
>
>> Signed-off-by: Kazuhito Hagio <k-hagio-ab(a)nec.com>
>> ---
>> symbols.c | 6 +++---
>> 1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/symbols.c b/symbols.c
>> index bee1faf..42c4eb4 100644
>> --- a/symbols.c
>> +++ b/symbols.c
>> @@ -7351,7 +7351,7 @@ cmd_p(void)
>> unsigned radix;
>> int do_load_module_filter;
>> char buf1[BUFSIZE];
>> - char *cpuspec;
>> + char *cpuspec, *p;
>>
>> do_load_module_filter = radix = 0;
>>
>> @@ -7386,7 +7386,7 @@ cmd_p(void)
>> if (argerrs || !args[optind])
>> cmd_usage(pc->curcmd, SYNOPSIS);
>>
>> - cpuspec = strrchr(args[optind], ':');
>> + p = cpuspec = strrchr(args[optind], ':');
>> if (cpuspec)
>> *cpuspec++ = NULLCHAR;
>>
>> @@ -7409,7 +7409,7 @@ cmd_p(void)
>> sp->name);
>> else
>> /* maybe a valid C expression (e.g. ':') */
>> - *(cpuspec-1) = ':';
>> + *p = ':';
>> }
>>
>> process_gdb_output(concat_args(buf1, 0, TRUE), radix,
>> --
>> 2.31.1
>>
1:52 a.m.
New subject: [PATCH 2/4] Fix gcc-11 compilation warning on symbols.c
On Tue, Jul 26, 2022 at 12:21 PM HAGIO KAZUHITO(萩尾 一仁) <k-hagio-ab(a)nec.com>
wrote:
Hi Lianbo,
thanks for the review.
On 2022/07/25 15:30, lijiang wrote:
> Hi, Kazu
> Thank you for the fix.
>
> On Fri, Jul 22, 2022 at 12:45 PM HAGIO KAZUHITO(萩尾 一仁) <
k-hagio-ab(a)nec.com>
> wrote:
>
>> Without the patch, the following gcc-11 compliation warning is emitted
>> for symbols.c:
>>
>> symbols.c: In function 'cmd_p':
>> symbols.c:7412:38: warning: writing 1 byte into a region of size 0
>> [-Wstringop-overflow=]
>> 7412 | *(cpuspec-1) = ':';
>> | ~~~~~~~~~~~~~^~~~~
>>
>
>
> I have one question about it:
> This issue only appears in gcc-11 and earlier, I tested it with gcc-12,
but
> it disappeared. It's interesting.
I think that the warning is a false detection. This patch has no behavior
change, just a cosmetic change to avoid the warning. I'm not sure, but it
might be a gcc bug and fixed in gcc-12.
Probably. Let's leave it there, if it still appears in the future, we can
pick it up. Any thoughts?
The other three patches look good to me: Ack.
[PATCH 1/4] Fix gcc-11 compilation warnings on filesys.c
[PATCH 3/4] Fix gcc-11 compilation warning on makedumpfile.c
[PATCH 4/4] Fix gcc-11 compilation warning on kvmdump.c
Thanks.
Lianbo
Thanks,
Kazu
>
> In addition, a new warning was found(gcc-12), but it is not related to
this
> patch.
> ...
> gcc -c -g -DX86_64 -DLZO -DGDB_10_2 -g -O2 lkcd_v1.c -DMCLX -Wall -O2
> -Wstrict-prototypes -Wmissing-prototypes -fstack-protector
-Wformat-security
> lkcd_v1.c: In function ‘dump_lkcd_environment_v1’:
> lkcd_v1.c:252:20: warning: the comparison will always evaluate as ‘true’
> for the address of ‘dh_panic_string’ will never be NULL [-Waddress]
> 252 | dh && dh->dh_panic_string &&
> | ^~
> In file included from lkcd_v1.c:21:
> lkcd_vmdump_v1.h:108:30: note: ‘dh_panic_string’ declared here
> 108 | char dh_panic_string[DUMP_PANIC_LEN];
> | ^~~~~~~~~~~~~~~
> gcc -c -g -DX86_64 -DLZO -DGDB_10_2 -g -O2 lkcd_v2_v3.c -DMCLX -Wall -O2
> -Wstrict-prototypes -Wmissing-prototypes -fstack-protector
-Wformat-security
> lkcd_v2_v3.c: In function ‘dump_lkcd_environment_v2_v3’:
> lkcd_v2_v3.c:310:20: warning: the comparison will always evaluate as
‘true’
> for the address of ‘dh_panic_string’ will never be NULL [-Waddress]
> 310 | dh && dh->dh_panic_string &&
> | ^~
> In file included from lkcd_v2_v3.c:21:
> lkcd_vmdump_v2_v3.h:205:30: note: ‘dh_panic_string’ declared here
> 205 | char dh_panic_string[DUMP_PANIC_LEN];
> | ^~~~~~~~~~~~~~~
> gcc -c -g -DX86_64 -DLZO -DGDB_10_2 -g -O2 lkcd_v5.c -DMCLX -Wall -O2
> -Wstrict-prototypes -Wmissing-prototypes -fstack-protector
-Wformat-security
> lkcd_v5.c: In function ‘dump_lkcd_environment_v5’:
> lkcd_v5.c:273:20: warning: the comparison will always evaluate as ‘true’
> for the address of ‘dh_panic_string’ will never be NULL [-Waddress]
> 273 | dh && dh->dh_panic_string &&
> | ^~
> In file included from lkcd_v5.c:20:
> lkcd_dump_v5.h:163:30: note: ‘dh_panic_string’ declared here
> 163 | char dh_panic_string[DUMP_PANIC_LEN];
> | ^~~~~~~~~~~~~~~
> gcc -c -g -DX86_64 -DLZO -DGDB_10_2 -g -O2 lkcd_v7.c -DMCLX -Wall -O2
> -Wstrict-prototypes -Wmissing-prototypes -fstack-protector
-Wformat-security
> lkcd_v7.c: In function ‘dump_lkcd_environment_v7’:
> lkcd_v7.c:350:20: warning: the comparison will always evaluate as ‘true’
> for the address of ‘dh_panic_string’ will never be NULL [-Waddress]
> 350 | dh && dh->dh_panic_string &&
> | ^~
> In file included from lkcd_v7.c:21:
> lkcd_dump_v5.h:163:30: note: ‘dh_panic_string’ declared here
> 163 | char dh_panic_string[DUMP_PANIC_LEN];
> | ^~~~~~~~~~~~~~~
> gcc -c -g -DX86_64 -DLZO -DGDB_10_2 -g -O2 lkcd_v8.c -DMCLX -Wall -O2
> -Wstrict-prototypes -Wmissing-prototypes -fstack-protector
-Wformat-security
> lkcd_v8.c: In function ‘dump_lkcd_environment_v8’:
> lkcd_v8.c:546:20: warning: the comparison will always evaluate as ‘true’
> for the address of ‘dh_panic_string’ will never be NULL [-Waddress]
> 546 | dh && dh->dh_panic_string &&
> | ^~
> In file included from lkcd_v8.c:23:
> lkcd_dump_v8.h:165:30: note: ‘dh_panic_string’ declared here
> 165 | char dh_panic_string[DUMP_PANIC_LEN];
> ...
>
> Thanks.
> Lianbo
>
>
>> Signed-off-by: Kazuhito Hagio <k-hagio-ab(a)nec.com>
>> ---
>> symbols.c | 6 +++---
>> 1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/symbols.c b/symbols.c
>> index bee1faf..42c4eb4 100644
>> --- a/symbols.c
>> +++ b/symbols.c
>> @@ -7351,7 +7351,7 @@ cmd_p(void)
>> unsigned radix;
>> int do_load_module_filter;
>> char buf1[BUFSIZE];
>> - char *cpuspec;
>> + char *cpuspec, *p;
>>
>> do_load_module_filter = radix = 0;
>>
>> @@ -7386,7 +7386,7 @@ cmd_p(void)
>> if (argerrs || !args[optind])
>> cmd_usage(pc->curcmd, SYNOPSIS);
>>
>> - cpuspec = strrchr(args[optind], ':');
>> + p = cpuspec = strrchr(args[optind], ':');
>> if (cpuspec)
>> *cpuspec++ = NULLCHAR;
>>
>> @@ -7409,7 +7409,7 @@ cmd_p(void)
>> sp->name);
>> else
>> /* maybe a valid C expression (e.g. ':') */
>> - *(cpuspec-1) = ':';
>> + *p = ':';
>> }
>>
>> process_gdb_output(concat_args(buf1, 0, TRUE), radix,
>> --
>> 2.31.1
>>
2:24 a.m.
New subject: [PATCH 2/4] Fix gcc-11 compilation warning on symbols.c
On 2022/07/26 15:52, lijiang wrote:>>>> Without the patch, the following
gcc-11 compliation warning is emitted
>>> for symbols.c:
>>>
>>> symbols.c: In function 'cmd_p':
>>> symbols.c:7412:38: warning: writing 1 byte into a region of size 0
>>> [-Wstringop-overflow=]
>>> 7412 | *(cpuspec-1) = ':';
>>> | ~~~~~~~~~~~~~^~~~~
>>>
>>
>>
>> I have one question about it:
>> This issue only appears in gcc-11 and earlier, I tested it with gcc-12,
> but
>> it disappeared. It's interesting.
> I think that the warning is a false detection. This patch has no behavior
> change, just a cosmetic change to avoid the warning. I'm not sure, but it
> might be a gcc bug and fixed in gcc-12.
>
Probably. Let's leave it there, if it still appears in the future, we can
pick it up. Any thoughts?
um, I see the warning on RHEL9, what is your concern about fixing this?
I think it's not bad to suppress this for users/distros using gcc-11,
with the small cosmetic change, not harmful.
The other three patches look good to me: Ack.
[PATCH 1/4] Fix gcc-11 compilation warnings on filesys.c
[PATCH 3/4] Fix gcc-11 compilation warning on makedumpfile.c
[PATCH 4/4] Fix gcc-11 compilation warning on kvmdump.c
Thanks!
Kazu
3:06 a.m.
New subject: [PATCH 2/4] Fix gcc-11 compilation warning on symbols.c
On Tue, Jul 26, 2022 at 3:24 PM HAGIO KAZUHITO(萩尾 一仁) <k-hagio-ab(a)nec.com>
wrote:
On 2022/07/26 15:52, lijiang wrote:>>>> Without the
patch, the following
gcc-11 compliation warning is emitted
>>>> for symbols.c:
>>>>
>>>> symbols.c: In function 'cmd_p':
>>>> symbols.c:7412:38: warning: writing 1 byte into a region of size 0
>>>> [-Wstringop-overflow=]
>>>> 7412 | *(cpuspec-1) = ':';
>>>> | ~~~~~~~~~~~~~^~~~~
>>>>
>>>
>>>
>>> I have one question about it:
>>> This issue only appears in gcc-11 and earlier, I tested it with gcc-12,
>> but
>>> it disappeared. It's interesting.
>> I think that the warning is a false detection. This patch has no
behavior
>> change, just a cosmetic change to avoid the warning. I'm not sure, but
it
>> might be a gcc bug and fixed in gcc-12.
>>
>
> Probably. Let's leave it there, if it still appears in the future, we
can
> pick it up. Any thoughts?
um, I see the warning on RHEL9, what is your concern about fixing this?
If it is not a real issue, we may not need to apply additional patches.
I think it's not bad to suppress this for users/distros using gcc-11,
with the small cosmetic change, not harmful.
However, I can help to ack this one, if you would like to have it.
Thanks.
Lianbo
The other three patches look good to me: Ack.
> [PATCH 1/4] Fix gcc-11 compilation warnings on filesys.c
> [PATCH 3/4] Fix gcc-11 compilation warning on makedumpfile.c
> [PATCH 4/4] Fix gcc-11 compilation warning on kvmdump.c
Thanks!
Kazu
3:54 a.m.
New subject: [PATCH 2/4] Fix gcc-11 compilation warning on symbols.c
On 2022/07/26 17:06, lijiang wrote:
On Tue, Jul 26, 2022 at 3:24 PM HAGIO KAZUHITO(萩尾 一仁)
<k-hagio-ab(a)nec.com>
wrote:
> On 2022/07/26 15:52, lijiang wrote:>>>> Without the patch, the
following
> gcc-11 compliation warning is emitted
>>>>> for symbols.c:
>>>>>
>>>>> symbols.c: In function 'cmd_p':
>>>>> symbols.c:7412:38: warning: writing 1 byte into a region of size 0
>>>>> [-Wstringop-overflow=]
>>>>> 7412 | *(cpuspec-1) = ':';
>>>>> | ~~~~~~~~~~~~~^~~~~
>>>>>
>>>>
>>>>
>>>> I have one question about it:
>>>> This issue only appears in gcc-11 and earlier, I tested it with gcc-12,
>>> but
>>>> it disappeared. It's interesting.
>>> I think that the warning is a false detection. This patch has no
> behavior
>>> change, just a cosmetic change to avoid the warning. I'm not sure, but
> it
>>> might be a gcc bug and fixed in gcc-12.
>>>
>>
>> Probably. Let's leave it there, if it still appears in the future, we
> can
>> pick it up. Any thoughts?
>
> um, I see the warning on RHEL9, what is your concern about fixing this?
>
If it is not a real issue, we may not need to apply additional patches.
Got it, thanks.
It's true that it is not crash's fault, but the warning itself is noisy and
might weaken our attention to new warnings. So I would like to suppress it
as far as we can, if a fix is not troublesome.
I think it's not bad to suppress this for users/distros using gcc-11,
> with the small cosmetic change, not harmful.
>
However, I can help to ack this one, if you would like to have it.
Thanks, Yes please.
Kazu
8:30 p.m.
New subject: [PATCH 2/4] Fix gcc-11 compilation warning on symbols.c
On Tue, Jul 26, 2022 at 4:55 PM HAGIO KAZUHITO(萩尾 一仁) <k-hagio-ab(a)nec.com>
wrote:
On 2022/07/26 17:06, lijiang wrote:
> On Tue, Jul 26, 2022 at 3:24 PM HAGIO KAZUHITO(萩尾 一仁) <
k-hagio-ab(a)nec.com>
> wrote:
>
>> On 2022/07/26 15:52, lijiang wrote:>>>> Without the patch, the
following
>> gcc-11 compliation warning is emitted
>>>>>> for symbols.c:
>>>>>>
>>>>>> symbols.c: In function 'cmd_p':
>>>>>> symbols.c:7412:38: warning: writing 1 byte into a region of size
0
>>>>>> [-Wstringop-overflow=]
>>>>>> 7412 | *(cpuspec-1) = ':';
>>>>>> | ~~~~~~~~~~~~~^~~~~
>>>>>>
>>>>>
>>>>>
>>>>> I have one question about it:
>>>>> This issue only appears in gcc-11 and earlier, I tested it with
gcc-12,
>>>> but
>>>>> it disappeared. It's interesting.
>>>> I think that the warning is a false detection. This patch has no
>> behavior
>>>> change, just a cosmetic change to avoid the warning. I'm not sure,
but
>> it
>>>> might be a gcc bug and fixed in gcc-12.
>>>>
>>>
>>> Probably. Let's leave it there, if it still appears in the future, we
>> can
>>> pick it up. Any thoughts?
>>
>> um, I see the warning on RHEL9, what is your concern about fixing this?
>>
>
> If it is not a real issue, we may not need to apply additional patches.
Got it, thanks.
It's true that it is not crash's fault, but the warning itself is noisy and
might weaken our attention to new warnings. So I would like to suppress it
as far as we can, if a fix is not troublesome.
Thank you for the explanation, Kazu.
>
> I think it's not bad to suppress this for users/distros using gcc-11,
>> with the small cosmetic change, not harmful.
>>
>
> However, I can help to ack this one, if you would like to have it.
Thanks, Yes please.
Ack for this patch.
Thanks.
Lianbo
Kazu
12:13 a.m.
New subject: [PATCH 2/4] Fix gcc-11 compilation warning on symbols.c
On 2022/07/27 10:30, lijiang wrote:>>> I think it's not bad to suppress this
for users/distros using gcc-11,
>>> with the small cosmetic change, not harmful.
>>>
>>
>> However, I can help to ack this one, if you would like to have it.
>
> Thanks, Yes please.
>
Ack for this patch.
Thank you for understanding, applied the series.
Kazu
705
days inactive
710
days old
devel@lists.crash-utility.osci.io
11 comments
2 participants
participants (2)
-
HAGIO KAZUHITO(萩尾 一仁) -
lijiang