Some more GCC10 -fanalyzer inspired patches

2020-05-10 Thread Mark Wielaard
I did another build with the final GCC10 and -fanalyzer. The -Wanalyzer-use-of-uninitialized-value option was removed, which caused a lot of false positives. Without those it was easier to identify some real issues. I also tried -fanalyze together with -flto. This takes a lot of memory (linking lib

[PATCH 1/7] libdwfl: Cleanup user_core resources on failure in dwfl_core_file_report.

2020-05-10 Thread Mark Wielaard
GCC10 -fanalyzer noticed that we allocate, but don't always cleanup the dwfl->user_core if it wasn't set yet on error. In theory dwfl_module_end should take care of it, but it is cleaner and less confusing to just do it here. Signed-off-by: Mark Wielaard --- libdwfl/ChangeLog | 6 ++ libd

[PATCH 2/7] tests: Make sure to not call memcmp with NULL arguments.

2020-05-10 Thread Mark Wielaard
GCC10 -fanalyzer thinks we are too clever: elfputzdata.c: In function ‘main’: elfputzdata.c:178:8: warning: use of possibly-NULL ‘orig_buf’ where non-null expected [CWE-690] [-Wanalyzer-possible-null-argument] 178 | && memcmp (orig_buf, d->d_buf, ori

[PATCH 4/7] libelf: Check for NULL shdr in elf_strptr.

2020-05-10 Thread Mark Wielaard
GCC10 -fanalyzer with -flto notices __elf64_getshdr_rdlock can fail and because the result isn't checked in elf_strptr it can cause a dereference of NULL. Signed-off-by: Mark Wielaard --- libelf/ChangeLog| 4 libelf/elf_strptr.c | 2 +- 2 files changed, 5 insertions(+), 1 deletion(-) d

[PATCH 3/7] libelf: Check __gelf_getehdr_rdlock call doesn't fail in elf_getdata.

2020-05-10 Thread Mark Wielaard
GCC10 -fanalyzer with -flto notices __gelf_getehdr_rdlock can fail and that the result of the call in __libelf_set_rawdata_wrlock isn't checked, which can cause a dereference of NULL. Signed-off-by: Mark Wielaard --- libelf/ChangeLog | 5 + libelf/elf_getdata.c | 2 ++ 2 files changed, 7

[PATCH 5/7] src: Check ebl_openbackend result before using ebl handle.

2020-05-10 Thread Mark Wielaard
GCC10 -fanalyzer plus -flto sees that ebl_openbackend can fail and return NULL. Most of the time we will get a dummy ebl, but in case of out of memory or corrupt ELF header it might return NULL. Make sure that we report a (fatal) error in that case in all tools. Signed-off-by: Mark Wielaard ---

[PATCH 6/7] libdwfl: Return failure from dwfl_standard_find_debuginfo for NULL module.

2020-05-10 Thread Mark Wielaard
GCC10 -fanalyzer plus -flto notices that some functions called by dwfl_standard_find_debuginfo check that the given module isn't NULL, but others expect it to be non-NULL. Just return a failure immediately when a NULL mod is passed to dwfl_standard_find_debuginfo. Signed-off-by: Mark Wielaard ---

[PATCH 7/7] libcpu: Free unused new bitfield on error in i386_parse.y new_bitfield.

2020-05-10 Thread Mark Wielaard
GCC10 -fanalyzer detected we didn't free the newly created bitfield on error. Make sure to free it before returning. Signed-off-by: Mark Wielaard --- libcpu/ChangeLog| 4 libcpu/i386_parse.y | 1 + 2 files changed, 5 insertions(+) diff --git a/libcpu/ChangeLog b/libcpu/ChangeLog index