[PATCH] gcc-sanitizers: fix -Werror=maybe-uninitialized issue

[PATCH] gcc-sanitizers: fix -Werror=maybe-uninitialized issue

[mingli.yu]

From: Mingli Yu <Mingli.Yu@windriver.com>

When DEBUG_BUILD = "1" added in local.conf, there
comes below build error when "bitbake gcc-sanitizers":
| ./../../../../../../../../work-shared/gcc-8.3.0-r0/gcc-8.3.0/libsanitizer/libbacktrace/../../libbacktrace/elf.c: In function 'elf_is_symlink':
| ../../../../../../../../../work-shared/gcc-8.3.0-r0/gcc-8.3.0/libsanitizer/libbacktrace/../../libbacktrace/elf.c:772:21: error: 'st.st_mode' may be used uninitialized in this function [-Werror=maybe-uninitialized]
|   return S_ISLNK (st.st_mode);

Initialize st_mode member to fix the above issue.

Signed-off-by: Mingli Yu <Mingli.Yu@windriver.com>
---
 meta/recipes-devtools/gcc/gcc-8.3.inc              |  1 +
 .../0041-elf.c-initialize-st_mode-member.patch     | 33 ++++++++++++++++++++++
 2 files changed, 34 insertions(+)
 create mode 100644 meta/recipes-devtools/gcc/gcc-8.3/0041-elf.c-initialize-st_mode-member.patch

diff --git a/meta/recipes-devtools/gcc/gcc-8.3.inc b/meta/recipes-devtools/gcc/gcc-8.3.inc
index f7bf257..3501325 100644
--- a/meta/recipes-devtools/gcc/gcc-8.3.inc
+++ b/meta/recipes-devtools/gcc/gcc-8.3.inc
@@ -71,6 +71,7 @@ SRC_URI = "\
            file://0038-Re-introduce-spe-commandline-options.patch \
            file://0039-riscv-Disable-multilib-for-OE.patch \
            file://0040-powerpc-powerpc64-Add-support-for-musl-ldso.patch \
+           file://0041-elf.c-initialize-st_mode-member.patch \
 "
 SRC_URI[md5sum] = "65b210b4bfe7e060051f799e0f994896"
 SRC_URI[sha256sum] = "64baadfe6cc0f4947a84cb12d7f0dfaf45bb58b7e92461639596c21e02d97d2c"
diff --git a/meta/recipes-devtools/gcc/gcc-8.3/0041-elf.c-initialize-st_mode-member.patch b/meta/recipes-devtools/gcc/gcc-8.3/0041-elf.c-initialize-st_mode-member.patch
new file mode 100644
index 0000000..8e80c4e
--- /dev/null
+++ b/meta/recipes-devtools/gcc/gcc-8.3/0041-elf.c-initialize-st_mode-member.patch
@@ -0,0 +1,33 @@
+From 960f3e1f104192ceb80a97e665fadffda5285aab Mon Sep 17 00:00:00 2001
+From: Mingli Yu <Mingli.Yu@windriver.com>
+Date: Tue, 19 Mar 2019 16:23:04 +0800
+Subject: [PATCH] elf.c: initialize st_mode member
+
+Initialize st_mode member to fix the below
+build failure when -Og included in compiler flag.
+| ./../../../../../../../../work-shared/gcc-8.3.0-r0/gcc-8.3.0/libsanitizer/libbacktrace/../../libbacktrace/elf.c: In function 'elf_is_symlink':
+| ../../../../../../../../../work-shared/gcc-8.3.0-r0/gcc-8.3.0/libsanitizer/libbacktrace/../../libbacktrace/elf.c:772:21: error: 'st.st_mode' may be used uninitialized in this function [-Werror=maybe-uninitialized]
+   return S_ISLNK (st.st_mode);
+
+Upstream-Status: Submitted[https://gcc.gnu.org/ml/gcc-patches/2019-03/msg00900.html]
+
+Signed-off-by: Mingli Yu <Mingli.Yu@windriver.com>
+---
+ libbacktrace/elf.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/libbacktrace/elf.c b/libbacktrace/elf.c
+index f4863f0..561bdc2 100644
+--- a/libbacktrace/elf.c
++++ b/libbacktrace/elf.c
+@@ -766,6 +766,7 @@ static int
+ elf_is_symlink (const char *filename)
+ {
+   struct stat st;
++  st.st_mode = 0;
+ 
+   if (lstat (filename, &st) < 0)
+     return 0;
+-- 
+2.7.4
+
-- 
2.7.4

Re: [PATCH] gcc-sanitizers: fix -Werror=maybe-uninitialized issue

[Yu, Mingli]

Ping.

Thanks,

On 2019年03月19日 16:44, mingli.yu@windriver.com wrote:
> From: Mingli Yu <Mingli.Yu@windriver.com>
>
> When DEBUG_BUILD = "1" added in local.conf, there
> comes below build error when "bitbake gcc-sanitizers":
> | ./../../../../../../../../work-shared/gcc-8.3.0-r0/gcc-8.3.0/libsanitizer/libbacktrace/../../libbacktrace/elf.c: In function 'elf_is_symlink':
> | ../../../../../../../../../work-shared/gcc-8.3.0-r0/gcc-8.3.0/libsanitizer/libbacktrace/../../libbacktrace/elf.c:772:21: error: 'st.st_mode' may be used uninitialized in this function [-Werror=maybe-uninitialized]
> |   return S_ISLNK (st.st_mode);
>
> Initialize st_mode member to fix the above issue.
>
> Signed-off-by: Mingli Yu <Mingli.Yu@windriver.com>
> ---
>   meta/recipes-devtools/gcc/gcc-8.3.inc              |  1 +
>   .../0041-elf.c-initialize-st_mode-member.patch     | 33 ++++++++++++++++++++++
>   2 files changed, 34 insertions(+)
>   create mode 100644 meta/recipes-devtools/gcc/gcc-8.3/0041-elf.c-initialize-st_mode-member.patch
>
> diff --git a/meta/recipes-devtools/gcc/gcc-8.3.inc b/meta/recipes-devtools/gcc/gcc-8.3.inc
> index f7bf257..3501325 100644
> --- a/meta/recipes-devtools/gcc/gcc-8.3.inc
> +++ b/meta/recipes-devtools/gcc/gcc-8.3.inc
> @@ -71,6 +71,7 @@ SRC_URI = "\
>              file://0038-Re-introduce-spe-commandline-options.patch \
>              file://0039-riscv-Disable-multilib-for-OE.patch \
>              file://0040-powerpc-powerpc64-Add-support-for-musl-ldso.patch \
> +           file://0041-elf.c-initialize-st_mode-member.patch \
>   "
>   SRC_URI[md5sum] = "65b210b4bfe7e060051f799e0f994896"
>   SRC_URI[sha256sum] = "64baadfe6cc0f4947a84cb12d7f0dfaf45bb58b7e92461639596c21e02d97d2c"
> diff --git a/meta/recipes-devtools/gcc/gcc-8.3/0041-elf.c-initialize-st_mode-member.patch b/meta/recipes-devtools/gcc/gcc-8.3/0041-elf.c-initialize-st_mode-member.patch
> new file mode 100644
> index 0000000..8e80c4e
> --- /dev/null
> +++ b/meta/recipes-devtools/gcc/gcc-8.3/0041-elf.c-initialize-st_mode-member.patch
> @@ -0,0 +1,33 @@
> +From 960f3e1f104192ceb80a97e665fadffda5285aab Mon Sep 17 00:00:00 2001
> +From: Mingli Yu <Mingli.Yu@windriver.com>
> +Date: Tue, 19 Mar 2019 16:23:04 +0800
> +Subject: [PATCH] elf.c: initialize st_mode member
> +
> +Initialize st_mode member to fix the below
> +build failure when -Og included in compiler flag.
> +| ./../../../../../../../../work-shared/gcc-8.3.0-r0/gcc-8.3.0/libsanitizer/libbacktrace/../../libbacktrace/elf.c: In function 'elf_is_symlink':
> +| ../../../../../../../../../work-shared/gcc-8.3.0-r0/gcc-8.3.0/libsanitizer/libbacktrace/../../libbacktrace/elf.c:772:21: error: 'st.st_mode' may be used uninitialized in this function [-Werror=maybe-uninitialized]
> +   return S_ISLNK (st.st_mode);
> +
> +Upstream-Status: Submitted[https://gcc.gnu.org/ml/gcc-patches/2019-03/msg00900.html]
> +
> +Signed-off-by: Mingli Yu <Mingli.Yu@windriver.com>
> +---
> + libbacktrace/elf.c | 1 +
> + 1 file changed, 1 insertion(+)
> +
> +diff --git a/libbacktrace/elf.c b/libbacktrace/elf.c
> +index f4863f0..561bdc2 100644
> +--- a/libbacktrace/elf.c
> ++++ b/libbacktrace/elf.c
> +@@ -766,6 +766,7 @@ static int
> + elf_is_symlink (const char *filename)
> + {
> +   struct stat st;
> ++  st.st_mode = 0;
> +
> +   if (lstat (filename, &st) < 0)
> +     return 0;
> +--
> +2.7.4
> +
>

Re: [PATCH] gcc-sanitizers: fix -Werror=maybe-uninitialized issue

[Yu, Mingli]

Ping.

Any comments here?

Thanks,

On 2019年03月19日 16:44, mingli.yu@windriver.com wrote:
> From: Mingli Yu <Mingli.Yu@windriver.com>
>
> When DEBUG_BUILD = "1" added in local.conf, there
> comes below build error when "bitbake gcc-sanitizers":
> | ./../../../../../../../../work-shared/gcc-8.3.0-r0/gcc-8.3.0/libsanitizer/libbacktrace/../../libbacktrace/elf.c: In function 'elf_is_symlink':
> | ../../../../../../../../../work-shared/gcc-8.3.0-r0/gcc-8.3.0/libsanitizer/libbacktrace/../../libbacktrace/elf.c:772:21: error: 'st.st_mode' may be used uninitialized in this function [-Werror=maybe-uninitialized]
> |   return S_ISLNK (st.st_mode);
>
> Initialize st_mode member to fix the above issue.
>
> Signed-off-by: Mingli Yu <Mingli.Yu@windriver.com>
> ---
>   meta/recipes-devtools/gcc/gcc-8.3.inc              |  1 +
>   .../0041-elf.c-initialize-st_mode-member.patch     | 33 ++++++++++++++++++++++
>   2 files changed, 34 insertions(+)
>   create mode 100644 meta/recipes-devtools/gcc/gcc-8.3/0041-elf.c-initialize-st_mode-member.patch
>
> diff --git a/meta/recipes-devtools/gcc/gcc-8.3.inc b/meta/recipes-devtools/gcc/gcc-8.3.inc
> index f7bf257..3501325 100644
> --- a/meta/recipes-devtools/gcc/gcc-8.3.inc
> +++ b/meta/recipes-devtools/gcc/gcc-8.3.inc
> @@ -71,6 +71,7 @@ SRC_URI = "\
>              file://0038-Re-introduce-spe-commandline-options.patch \
>              file://0039-riscv-Disable-multilib-for-OE.patch \
>              file://0040-powerpc-powerpc64-Add-support-for-musl-ldso.patch \
> +           file://0041-elf.c-initialize-st_mode-member.patch \
>   "
>   SRC_URI[md5sum] = "65b210b4bfe7e060051f799e0f994896"
>   SRC_URI[sha256sum] = "64baadfe6cc0f4947a84cb12d7f0dfaf45bb58b7e92461639596c21e02d97d2c"
> diff --git a/meta/recipes-devtools/gcc/gcc-8.3/0041-elf.c-initialize-st_mode-member.patch b/meta/recipes-devtools/gcc/gcc-8.3/0041-elf.c-initialize-st_mode-member.patch
> new file mode 100644
> index 0000000..8e80c4e
> --- /dev/null
> +++ b/meta/recipes-devtools/gcc/gcc-8.3/0041-elf.c-initialize-st_mode-member.patch
> @@ -0,0 +1,33 @@
> +From 960f3e1f104192ceb80a97e665fadffda5285aab Mon Sep 17 00:00:00 2001
> +From: Mingli Yu <Mingli.Yu@windriver.com>
> +Date: Tue, 19 Mar 2019 16:23:04 +0800
> +Subject: [PATCH] elf.c: initialize st_mode member
> +
> +Initialize st_mode member to fix the below
> +build failure when -Og included in compiler flag.
> +| ./../../../../../../../../work-shared/gcc-8.3.0-r0/gcc-8.3.0/libsanitizer/libbacktrace/../../libbacktrace/elf.c: In function 'elf_is_symlink':
> +| ../../../../../../../../../work-shared/gcc-8.3.0-r0/gcc-8.3.0/libsanitizer/libbacktrace/../../libbacktrace/elf.c:772:21: error: 'st.st_mode' may be used uninitialized in this function [-Werror=maybe-uninitialized]
> +   return S_ISLNK (st.st_mode);
> +
> +Upstream-Status: Submitted[https://gcc.gnu.org/ml/gcc-patches/2019-03/msg00900.html]
> +
> +Signed-off-by: Mingli Yu <Mingli.Yu@windriver.com>
> +---
> + libbacktrace/elf.c | 1 +
> + 1 file changed, 1 insertion(+)
> +
> +diff --git a/libbacktrace/elf.c b/libbacktrace/elf.c
> +index f4863f0..561bdc2 100644
> +--- a/libbacktrace/elf.c
> ++++ b/libbacktrace/elf.c
> +@@ -766,6 +766,7 @@ static int
> + elf_is_symlink (const char *filename)
> + {
> +   struct stat st;
> ++  st.st_mode = 0;
> +
> +   if (lstat (filename, &st) < 0)
> +     return 0;
> +--
> +2.7.4
> +
>

Re: [PATCH] gcc-sanitizers: fix -Werror=maybe-uninitialized issue

[Khem Raj]

On Tue, Mar 19, 2019 at 1:45 AM <mingli.yu@windriver.com> wrote:
>
> From: Mingli Yu <Mingli.Yu@windriver.com>
>
> When DEBUG_BUILD = "1" added in local.conf, there
> comes below build error when "bitbake gcc-sanitizers":
> | ./../../../../../../../../work-shared/gcc-8.3.0-r0/gcc-8.3.0/libsanitizer/libbacktrace/../../libbacktrace/elf.c: In function 'elf_is_symlink':
> | ../../../../../../../../../work-shared/gcc-8.3.0-r0/gcc-8.3.0/libsanitizer/libbacktrace/../../libbacktrace/elf.c:772:21: error: 'st.st_mode' may be used uninitialized in this function [-Werror=maybe-uninitialized]
> |   return S_ISLNK (st.st_mode);
>
> Initialize st_mode member to fix the above issue.
>
> Signed-off-by: Mingli Yu <Mingli.Yu@windriver.com>
> ---
>  meta/recipes-devtools/gcc/gcc-8.3.inc              |  1 +
>  .../0041-elf.c-initialize-st_mode-member.patch     | 33 ++++++++++++++++++++++
>  2 files changed, 34 insertions(+)
>  create mode 100644 meta/recipes-devtools/gcc/gcc-8.3/0041-elf.c-initialize-st_mode-member.patch
>
> diff --git a/meta/recipes-devtools/gcc/gcc-8.3.inc b/meta/recipes-devtools/gcc/gcc-8.3.inc
> index f7bf257..3501325 100644
> --- a/meta/recipes-devtools/gcc/gcc-8.3.inc
> +++ b/meta/recipes-devtools/gcc/gcc-8.3.inc
> @@ -71,6 +71,7 @@ SRC_URI = "\
>             file://0038-Re-introduce-spe-commandline-options.patch \
>             file://0039-riscv-Disable-multilib-for-OE.patch \
>             file://0040-powerpc-powerpc64-Add-support-for-musl-ldso.patch \
> +           file://0041-elf.c-initialize-st_mode-member.patch \
>  "
>  SRC_URI[md5sum] = "65b210b4bfe7e060051f799e0f994896"
>  SRC_URI[sha256sum] = "64baadfe6cc0f4947a84cb12d7f0dfaf45bb58b7e92461639596c21e02d97d2c"
> diff --git a/meta/recipes-devtools/gcc/gcc-8.3/0041-elf.c-initialize-st_mode-member.patch b/meta/recipes-devtools/gcc/gcc-8.3/0041-elf.c-initialize-st_mode-member.patch
> new file mode 100644
> index 0000000..8e80c4e
> --- /dev/null
> +++ b/meta/recipes-devtools/gcc/gcc-8.3/0041-elf.c-initialize-st_mode-member.patch
> @@ -0,0 +1,33 @@
> +From 960f3e1f104192ceb80a97e665fadffda5285aab Mon Sep 17 00:00:00 2001
> +From: Mingli Yu <Mingli.Yu@windriver.com>
> +Date: Tue, 19 Mar 2019 16:23:04 +0800
> +Subject: [PATCH] elf.c: initialize st_mode member
> +
> +Initialize st_mode member to fix the below
> +build failure when -Og included in compiler flag.
> +| ./../../../../../../../../work-shared/gcc-8.3.0-r0/gcc-8.3.0/libsanitizer/libbacktrace/../../libbacktrace/elf.c: In function 'elf_is_symlink':
> +| ../../../../../../../../../work-shared/gcc-8.3.0-r0/gcc-8.3.0/libsanitizer/libbacktrace/../../libbacktrace/elf.c:772:21: error: 'st.st_mode' may be used uninitialized in this function [-Werror=maybe-uninitialized]
> +   return S_ISLNK (st.st_mode);
> +
> +Upstream-Status: Submitted[https://gcc.gnu.org/ml/gcc-patches/2019-03/msg00900.html]
> +
> +Signed-off-by: Mingli Yu <Mingli.Yu@windriver.com>
> +---
> + libbacktrace/elf.c | 1 +
> + 1 file changed, 1 insertion(+)
> +
> +diff --git a/libbacktrace/elf.c b/libbacktrace/elf.c
> +index f4863f0..561bdc2 100644
> +--- a/libbacktrace/elf.c
> ++++ b/libbacktrace/elf.c
> +@@ -766,6 +766,7 @@ static int
> + elf_is_symlink (const char *filename)
> + {
> +   struct stat st;
> ++  st.st_mode = 0;

perhaps its safer to initialize whole struct to 0

 struct stat st = {0};

> +
> +   if (lstat (filename, &st) < 0)
> +     return 0;
> +--
> +2.7.4
> +
> --
> 2.7.4
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

[PATCH v2] gcc-sanitizers: fix -Werror=maybe-uninitialized issue

[mingli.yu]

From: Mingli Yu <Mingli.Yu@windriver.com>

When DEBUG_BUILD = "1" added in local.conf, there
comes below build error when "bitbake gcc-sanitizers":
| ./../../../../../../../../work-shared/gcc-8.3.0-r0/gcc-8.3.0/libsanitizer/libbacktrace/../../libbacktrace/elf.c: In function 'elf_is_symlink':
| ../../../../../../../../../work-shared/gcc-8.3.0-r0/gcc-8.3.0/libsanitizer/libbacktrace/../../libbacktrace/elf.c:772:21: error: 'st.st_mode' may be used uninitialized in this function [-Werror=maybe-uninitialized]
|   return S_ISLNK (st.st_mode);

Initialize struct stat to fix the above issue.

Signed-off-by: Mingli Yu <Mingli.Yu@windriver.com>
---
 meta/recipes-devtools/gcc/gcc-8.3.inc              |  1 +
 .../0041-elf.c-initialize-struct-stat.patch        | 34 ++++++++++++++++++++++
 2 files changed, 35 insertions(+)
 create mode 100644 meta/recipes-devtools/gcc/gcc-8.3/0041-elf.c-initialize-struct-stat.patch

diff --git a/meta/recipes-devtools/gcc/gcc-8.3.inc b/meta/recipes-devtools/gcc/gcc-8.3.inc
index f7bf257..317c6af 100644
--- a/meta/recipes-devtools/gcc/gcc-8.3.inc
+++ b/meta/recipes-devtools/gcc/gcc-8.3.inc
@@ -71,6 +71,7 @@ SRC_URI = "\
            file://0038-Re-introduce-spe-commandline-options.patch \
            file://0039-riscv-Disable-multilib-for-OE.patch \
            file://0040-powerpc-powerpc64-Add-support-for-musl-ldso.patch \
+           file://0041-elf.c-initialize-struct-stat.patch \
 "
 SRC_URI[md5sum] = "65b210b4bfe7e060051f799e0f994896"
 SRC_URI[sha256sum] = "64baadfe6cc0f4947a84cb12d7f0dfaf45bb58b7e92461639596c21e02d97d2c"
diff --git a/meta/recipes-devtools/gcc/gcc-8.3/0041-elf.c-initialize-struct-stat.patch b/meta/recipes-devtools/gcc/gcc-8.3/0041-elf.c-initialize-struct-stat.patch
new file mode 100644
index 0000000..56d62c9
--- /dev/null
+++ b/meta/recipes-devtools/gcc/gcc-8.3/0041-elf.c-initialize-struct-stat.patch
@@ -0,0 +1,34 @@
+From eae259e4722a1c4606a1e6df7ee84a311a91f4a6 Mon Sep 17 00:00:00 2001
+From: Mingli Yu <Mingli.Yu@windriver.com>
+Date: Mon, 8 Apr 2019 14:19:31 +0800
+Subject: [PATCH] elf.c: initialize struct stat
+
+Initialize struct stat to fix the below
+build failure when -Og included in compiler flag.
+| ./../../../../../../../../work-shared/gcc-8.3.0-r0/gcc-8.3.0/libsanitizer/libbacktrace/../../libbacktrace/elf.c: In function 'elf_is_symlink':
+| ../../../../../../../../../work-shared/gcc-8.3.0-r0/gcc-8.3.0/libsanitizer/libbacktrace/../../libbacktrace/elf.c:772:21: error: 'st.st_mode' may be used uninitialized in this function [-Werror=maybe-uninitialized]
+   return S_ISLNK (st.st_mode);
+
+Upstream-Status: Submitted[https://gcc.gnu.org/ml/gcc-patches/2019-04/msg00261.html]
+
+Signed-off-by: Mingli Yu <Mingli.Yu@windriver.com>
+---
+ libbacktrace/elf.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/libbacktrace/elf.c b/libbacktrace/elf.c
+index f4863f0..8c57047 100644
+--- a/libbacktrace/elf.c
++++ b/libbacktrace/elf.c
+@@ -765,7 +765,7 @@ elf_syminfo (struct backtrace_state *state, uintptr_t addr,
+ static int
+ elf_is_symlink (const char *filename)
+ {
+-  struct stat st;
++  struct stat st = {0};
+ 
+   if (lstat (filename, &st) < 0)
+     return 0;
+-- 
+2.7.4
+
-- 
2.7.4

[PATCH v3] gcc-sanitizers: fix -Werror=maybe-uninitialized issue

[mingli.yu]

From: Mingli Yu <Mingli.Yu@windriver.com>

When DEBUG_BUILD = "1" added in local.conf, there
comes below build error when "bitbake gcc-sanitizers":
| ./../../../../../../../../work-shared/gcc-8.3.0-r0/gcc-8.3.0/libsanitizer/libbacktrace/../../libbacktrace/elf.c: In function 'elf_is_symlink':
| ../../../../../../../../../work-shared/gcc-8.3.0-r0/gcc-8.3.0/libsanitizer/libbacktrace/../../libbacktrace/elf.c:772:21: error: 'st.st_mode' may be used uninitialized in this function [-Werror=maybe-uninitialized]
|   return S_ISLNK (st.st_mode);

Per https://gcc.gnu.org/ml/gcc-patches/2019-04/msg00315.html,
the gcc upstream thinks the warning is a false
positive and suggests to use -O2 rather than -Og
or -O1 when compiling that file, so pass -Wno-error
to compiler when -Og is used to silence the error.

Signed-off-by: Mingli Yu <Mingli.Yu@windriver.com>
---
 meta/recipes-devtools/gcc/gcc-sanitizers.inc | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/meta/recipes-devtools/gcc/gcc-sanitizers.inc b/meta/recipes-devtools/gcc/gcc-sanitizers.inc
index e5e8452..8b1d1c9 100644
--- a/meta/recipes-devtools/gcc/gcc-sanitizers.inc
+++ b/meta/recipes-devtools/gcc/gcc-sanitizers.inc
@@ -45,6 +45,9 @@ INHIBIT_DEFAULT_DEPS = "1"
 ALLOW_EMPTY_${PN} = "1"
 DEPENDS = "gcc-runtime virtual/${TARGET_PREFIX}gcc"
 
+# used to fix ../../../../../../../../../work-shared/gcc-8.3.0-r0/gcc-8.3.0/libsanitizer/libbacktrace/../../libbacktrace/elf.c:772:21: error: 'st.st_mode' may be used uninitialized in this function [-Werror=maybe-uninitialized]
+DEBUG_OPTIMIZATION_append = " -Wno-error"
+
 BBCLASSEXTEND = "nativesdk"
 
 PACKAGES = "${PN} ${PN}-dbg"
-- 
2.7.4

Re: [PATCH v3] gcc-sanitizers: fix -Werror=maybe-uninitialized issue

[Khem Raj]

On Mon, Apr 8, 2019 at 7:32 PM <mingli.yu@windriver.com> wrote:
>
> From: Mingli Yu <Mingli.Yu@windriver.com>
>
> When DEBUG_BUILD = "1" added in local.conf, there
> comes below build error when "bitbake gcc-sanitizers":
> | ./../../../../../../../../work-shared/gcc-8.3.0-r0/gcc-8.3.0/libsanitizer/libbacktrace/../../libbacktrace/elf.c: In function 'elf_is_symlink':
> | ../../../../../../../../../work-shared/gcc-8.3.0-r0/gcc-8.3.0/libsanitizer/libbacktrace/../../libbacktrace/elf.c:772:21: error: 'st.st_mode' may be used uninitialized in this function [-Werror=maybe-uninitialized]
> |   return S_ISLNK (st.st_mode);
>
> Per https://gcc.gnu.org/ml/gcc-patches/2019-04/msg00315.html,
> the gcc upstream thinks the warning is a false
> positive and suggests to use -O2 rather than -Og
> or -O1 when compiling that file, so pass -Wno-error
> to compiler when -Og is used to silence the error.
>

Not particular to this change but in general if a package says that it
does not support -Og
then we are just going to get into more and more untested grounds
especially during runtime
so I wonder how useful it will be to use -Og for such packages or any
other non supported
combination for that matter.

> Signed-off-by: Mingli Yu <Mingli.Yu@windriver.com>
> ---
>  meta/recipes-devtools/gcc/gcc-sanitizers.inc | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/meta/recipes-devtools/gcc/gcc-sanitizers.inc b/meta/recipes-devtools/gcc/gcc-sanitizers.inc
> index e5e8452..8b1d1c9 100644
> --- a/meta/recipes-devtools/gcc/gcc-sanitizers.inc
> +++ b/meta/recipes-devtools/gcc/gcc-sanitizers.inc
> @@ -45,6 +45,9 @@ INHIBIT_DEFAULT_DEPS = "1"
>  ALLOW_EMPTY_${PN} = "1"
>  DEPENDS = "gcc-runtime virtual/${TARGET_PREFIX}gcc"
>
> +# used to fix ../../../../../../../../../work-shared/gcc-8.3.0-r0/gcc-8.3.0/libsanitizer/libbacktrace/../../libbacktrace/elf.c:772:21: error: 'st.st_mode' may be used uninitialized in this function [-Werror=maybe-uninitialized]
> +DEBUG_OPTIMIZATION_append = " -Wno-error"
> +
>  BBCLASSEXTEND = "nativesdk"
>
>  PACKAGES = "${PN} ${PN}-dbg"
> --
> 2.7.4
>

Re: [PATCH v3] gcc-sanitizers: fix -Werror=maybe-uninitialized issue

[Yu, Mingli]

On 2019年04月09日 11:53, Khem Raj wrote:
> On Mon, Apr 8, 2019 at 7:32 PM <mingli.yu@windriver.com> wrote:
>>
>> From: Mingli Yu <Mingli.Yu@windriver.com>
>>
>> When DEBUG_BUILD = "1" added in local.conf, there
>> comes below build error when "bitbake gcc-sanitizers":
>> | ./../../../../../../../../work-shared/gcc-8.3.0-r0/gcc-8.3.0/libsanitizer/libbacktrace/../../libbacktrace/elf.c: In function 'elf_is_symlink':
>> | ../../../../../../../../../work-shared/gcc-8.3.0-r0/gcc-8.3.0/libsanitizer/libbacktrace/../../libbacktrace/elf.c:772:21: error: 'st.st_mode' may be used uninitialized in this function [-Werror=maybe-uninitialized]
>> |   return S_ISLNK (st.st_mode);
>>
>> Per https://gcc.gnu.org/ml/gcc-patches/2019-04/msg00315.html,
>> the gcc upstream thinks the warning is a false
>> positive and suggests to use -O2 rather than -Og
>> or -O1 when compiling that file, so pass -Wno-error
>> to compiler when -Og is used to silence the error.
>>
>
> Not particular to this change but in general if a package says that it
> does not support -Og
> then we are just going to get into more and more untested grounds
> especially during runtime
> so I wonder how useful it will be to use -Og for such packages or any
> other non supported
> combination for that matter.

Hi Khem,

Any other suggestion to silence the gcc-sanitizers build error when 
DEBUG_BUILD is enabled?

Or just keep the logic DEBUG_OPTIMIZATION_append = " -Wno-error" as my 
patch stated?

Thanks,

>
>> Signed-off-by: Mingli Yu <Mingli.Yu@windriver.com>
>> ---
>>   meta/recipes-devtools/gcc/gcc-sanitizers.inc | 3 +++
>>   1 file changed, 3 insertions(+)
>>
>> diff --git a/meta/recipes-devtools/gcc/gcc-sanitizers.inc b/meta/recipes-devtools/gcc/gcc-sanitizers.inc
>> index e5e8452..8b1d1c9 100644
>> --- a/meta/recipes-devtools/gcc/gcc-sanitizers.inc
>> +++ b/meta/recipes-devtools/gcc/gcc-sanitizers.inc
>> @@ -45,6 +45,9 @@ INHIBIT_DEFAULT_DEPS = "1"
>>   ALLOW_EMPTY_${PN} = "1"
>>   DEPENDS = "gcc-runtime virtual/${TARGET_PREFIX}gcc"
>>
>> +# used to fix ../../../../../../../../../work-shared/gcc-8.3.0-r0/gcc-8.3.0/libsanitizer/libbacktrace/../../libbacktrace/elf.c:772:21: error: 'st.st_mode' may be used uninitialized in this function [-Werror=maybe-uninitialized]
>> +DEBUG_OPTIMIZATION_append = " -Wno-error"
>> +
>>   BBCLASSEXTEND = "nativesdk"
>>
>>   PACKAGES = "${PN} ${PN}-dbg"
>> --
>> 2.7.4
>>
>

Re: [PATCH v3] gcc-sanitizers: fix -Werror=maybe-uninitialized issue

[Adrian Bunk]

On Mon, Apr 08, 2019 at 08:53:49PM -0700, Khem Raj wrote:
> On Mon, Apr 8, 2019 at 7:32 PM <mingli.yu@windriver.com> wrote:
> >
> > From: Mingli Yu <Mingli.Yu@windriver.com>
> >
> > When DEBUG_BUILD = "1" added in local.conf, there
> > comes below build error when "bitbake gcc-sanitizers":
> > | ./../../../../../../../../work-shared/gcc-8.3.0-r0/gcc-8.3.0/libsanitizer/libbacktrace/../../libbacktrace/elf.c: In function 'elf_is_symlink':
> > | ../../../../../../../../../work-shared/gcc-8.3.0-r0/gcc-8.3.0/libsanitizer/libbacktrace/../../libbacktrace/elf.c:772:21: error: 'st.st_mode' may be used uninitialized in this function [-Werror=maybe-uninitialized]
> > |   return S_ISLNK (st.st_mode);
> >
> > Per https://gcc.gnu.org/ml/gcc-patches/2019-04/msg00315.html,
> > the gcc upstream thinks the warning is a false
> > positive and suggests to use -O2 rather than -Og
> > or -O1 when compiling that file, so pass -Wno-error
> > to compiler when -Og is used to silence the error.
> >
> 
> Not particular to this change but in general if a package says that it
> does not support -Og
> then we are just going to get into more and more untested grounds
> especially during runtime
> so I wonder how useful it will be to use -Og for such packages or any
> other non supported
> combination for that matter.

This has nothing to do with specific packages not supporting -Og
or any other combination, it is just about how to best workaround
a compiler bug temporarily.

gcc has bug(s) emitting bogus warnings with -Og, and these are build
failures with some packages that build with -Werror.

None of this is related to whether or not the packages will work
at runtime with -Og.

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [PATCH v3] gcc-sanitizers: fix -Werror=maybe-uninitialized issue

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 2532 bytes --]

On Mon, Apr 15, 2019 at 2:38 AM Adrian Bunk <bunk@stusta.de> wrote:

> On Mon, Apr 08, 2019 at 08:53:49PM -0700, Khem Raj wrote:
> > On Mon, Apr 8, 2019 at 7:32 PM <mingli.yu@windriver.com> wrote:
> > >
> > > From: Mingli Yu <Mingli.Yu@windriver.com>
> > >
> > > When DEBUG_BUILD = "1" added in local.conf, there
> > > comes below build error when "bitbake gcc-sanitizers":
> > > |
> ./../../../../../../../../work-shared/gcc-8.3.0-r0/gcc-8.3.0/libsanitizer/libbacktrace/../../libbacktrace/elf.c:
> In function 'elf_is_symlink':
> > > |
> ../../../../../../../../../work-shared/gcc-8.3.0-r0/gcc-8.3.0/libsanitizer/libbacktrace/../../libbacktrace/elf.c:772:21:
> error: 'st.st_mode' may be used uninitialized in this function
> [-Werror=maybe-uninitialized]
> > > |   return S_ISLNK (st.st_mode);
> > >
> > > Per https://gcc.gnu.org/ml/gcc-patches/2019-04/msg00315.html,
> > > the gcc upstream thinks the warning is a false
> > > positive and suggests to use -O2 rather than -Og
> > > or -O1 when compiling that file, so pass -Wno-error
> > > to compiler when -Og is used to silence the error.
> > >
> >
> > Not particular to this change but in general if a package says that it
> > does not support -Og
> > then we are just going to get into more and more untested grounds
> > especially during runtime
> > so I wonder how useful it will be to use -Og for such packages or any
> > other non supported
> > combination for that matter.
>
> This has nothing to do with specific packages not supporting -Og
> or any other combination, it is just about how to best workaround
> a compiler bug temporarily.
>
> gcc has bug(s) emitting bogus warnings with -Og, and these are build
> failures with some packages that build with -Werror.
>
> None of this is related to whether or not the packages will work
> at runtime with -Og.


What are you trying to convey ? That’s what I mentioned before I began my
reply however to reiterate my point was if a package is not usually built
and tested with this combination which is evident because it fails to build
then how good would it be if we fix this error especially complex packages
like compilers so is it worth to fix them or disable Og for them

>
>
> cu
> Adrian
>
> --
>
>        "Is there not promise of rain?" Ling Tan asked suddenly out
>         of the darkness. There had been need of rain for many days.
>        "Only a promise," Lao Er said.
>                                        Pearl S. Buck - Dragon Seed
>
>

[-- Attachment #2: Type: text/html, Size: 3470 bytes --]

Re: [PATCH v3] gcc-sanitizers: fix -Werror=maybe-uninitialized issue

[Adrian Bunk]

On Mon, Apr 15, 2019 at 07:19:13AM -0700, Khem Raj wrote:
> 
> What are you trying to convey ? That’s what I mentioned before I began my
> reply however to reiterate my point was if a package is not usually built
> and tested with this combination which is evident because it fails to build
> then how good would it be if we fix this error especially complex packages
> like compilers so is it worth to fix them or disable Og for them

Packages that usually get built and tested with -Og should be pretty rare,
and these specific build failures are better at finding the rare packages
that use -Werror than pointing at potential miscompilations.

From a distribution point of view, a package build with -Werror by 
default is arguably a bug since this frequently breaks when something
is changed (usually the compiler version).

-Og is better suited than the -O that was previously used for debugging,
but are we talking about debug builds or production builds?
If users would be using DEBUG_OPTIMIZATION in production builds that 
would be wrong - this will always be a mostly untested situation
with an increased probability of hitting bugs noone else has seen
before.

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [PATCH v3] gcc-sanitizers: fix -Werror=maybe-uninitialized issue

[Yu, Mingli]

On 2019年04月16日 00:21, Adrian Bunk wrote:
> On Mon, Apr 15, 2019 at 07:19:13AM -0700, Khem Raj wrote:
>>
>> What are you trying to convey ? That’s what I mentioned before I began my
>> reply however to reiterate my point was if a package is not usually built
>> and tested with this combination which is evident because it fails to build
>> then how good would it be if we fix this error especially complex packages
>> like compilers so is it worth to fix them or disable Og for them
>
> Packages that usually get built and tested with -Og should be pretty rare,
> and these specific build failures are better at finding the rare packages
> that use -Werror than pointing at potential miscompilations.
>
>>From a distribution point of view, a package build with -Werror by
> default is arguably a bug since this frequently breaks when something
> is changed (usually the compiler version).
>
> -Og is better suited than the -O that was previously used for debugging,
> but are we talking about debug builds or production builds?
> If users would be using DEBUG_OPTIMIZATION in production builds that

Thanks Adrian and Khem's response!
We indeed don't use DEBUG_OPTIMIZATION in production build.

But still comes question: how to silence gcc-sanitizers build failure 
when debug build enabled?

Thanks,

> would be wrong - this will always be a mostly untested situation
> with an increased probability of hitting bugs noone else has seen
> before.
>
> cu
> Adrian
>

Re: [PATCH v3] gcc-sanitizers: fix -Werror=maybe-uninitialized issue

[Khem Raj]

On Tue, Apr 16, 2019 at 1:40 AM Yu, Mingli <mingli.yu@windriver.com> wrote:
>
>
>
> On 2019年04月16日 00:21, Adrian Bunk wrote:
> > On Mon, Apr 15, 2019 at 07:19:13AM -0700, Khem Raj wrote:
> >>
> >> What are you trying to convey ? That’s what I mentioned before I began my
> >> reply however to reiterate my point was if a package is not usually built
> >> and tested with this combination which is evident because it fails to build
> >> then how good would it be if we fix this error especially complex packages
> >> like compilers so is it worth to fix them or disable Og for them
> >
> > Packages that usually get built and tested with -Og should be pretty rare,
> > and these specific build failures are better at finding the rare packages
> > that use -Werror than pointing at potential miscompilations.
> >
> >>From a distribution point of view, a package build with -Werror by
> > default is arguably a bug since this frequently breaks when something
> > is changed (usually the compiler version).
> >
> > -Og is better suited than the -O that was previously used for debugging,
> > but are we talking about debug builds or production builds?
> > If users would be using DEBUG_OPTIMIZATION in production builds that
>
> Thanks Adrian and Khem's response!
> We indeed don't use DEBUG_OPTIMIZATION in production build.
>
> But still comes question: how to silence gcc-sanitizers build failure
> when debug build enabled?
>
> Thanks,
>
> > would be wrong - this will always be a mostly untested situation
> > with an increased probability of hitting bugs noone else has seen
> > before.

disable warning as errors.

> >
> > cu
> > Adrian
> >

Re: [PATCH v3] gcc-sanitizers: fix -Werror=maybe-uninitialized issue

[Yu, Mingli]

On 2019年04月17日 02:00, Khem Raj wrote:
> On Tue, Apr 16, 2019 at 1:40 AM Yu, Mingli <mingli.yu@windriver.com> wrote:
>>
>>
>>
>> On 2019年04月16日 00:21, Adrian Bunk wrote:
>>> On Mon, Apr 15, 2019 at 07:19:13AM -0700, Khem Raj wrote:
>>>>
>>>> What are you trying to convey ? That’s what I mentioned before I began my
>>>> reply however to reiterate my point was if a package is not usually built
>>>> and tested with this combination which is evident because it fails to build
>>>> then how good would it be if we fix this error especially complex packages
>>>> like compilers so is it worth to fix them or disable Og for them
>>>
>>> Packages that usually get built and tested with -Og should be pretty rare,
>>> and these specific build failures are better at finding the rare packages
>>> that use -Werror than pointing at potential miscompilations.
>>>
>>> >From a distribution point of view, a package build with -Werror by
>>> default is arguably a bug since this frequently breaks when something
>>> is changed (usually the compiler version).
>>>
>>> -Og is better suited than the -O that was previously used for debugging,
>>> but are we talking about debug builds or production builds?
>>> If users would be using DEBUG_OPTIMIZATION in production builds that
>>
>> Thanks Adrian and Khem's response!
>> We indeed don't use DEBUG_OPTIMIZATION in production build.
>>
>> But still comes question: how to silence gcc-sanitizers build failure
>> when debug build enabled?
>>
>> Thanks,
>>
>>> would be wrong - this will always be a mostly untested situation
>>> with an increased probability of hitting bugs noone else has seen
>>> before.
>
> disable warning as errors.

Hi Khem,

I don't quite get what you mean. Disable warning as errors?

As https://gcc.gnu.org/ml/gcc-patches/2019-04/msg00315.html, gcc 
upstream thinks the build error is meaningless when compile 
gcc-sanitizers with -Og and suggests not use -Og to compile for 
gcc-sanitizers.

So I send out the patch to add the workaround [DEBUG_OPTIMIZATION_append 
= " -Wno-error"] to silence the error when debug build is enabled for 
gcc-sanitizers.
If the workaround isn't suitable, then how to silence the 
-Werror=maybe-uninitialized issue build error when debug build enabled?

Thanks,

>
>>>
>>> cu
>>> Adrian
>>>
>

Re: [PATCH v3] gcc-sanitizers: fix -Werror=maybe-uninitialized issue

[Khem Raj]

On Wed, Apr 17, 2019 at 12:45 AM Yu, Mingli <mingli.yu@windriver.com> wrote:
>
>
>
> On 2019年04月17日 02:00, Khem Raj wrote:
> > On Tue, Apr 16, 2019 at 1:40 AM Yu, Mingli <mingli.yu@windriver.com> wrote:
> >>
> >>
> >>
> >> On 2019年04月16日 00:21, Adrian Bunk wrote:
> >>> On Mon, Apr 15, 2019 at 07:19:13AM -0700, Khem Raj wrote:
> >>>>
> >>>> What are you trying to convey ? That’s what I mentioned before I began my
> >>>> reply however to reiterate my point was if a package is not usually built
> >>>> and tested with this combination which is evident because it fails to build
> >>>> then how good would it be if we fix this error especially complex packages
> >>>> like compilers so is it worth to fix them or disable Og for them
> >>>
> >>> Packages that usually get built and tested with -Og should be pretty rare,
> >>> and these specific build failures are better at finding the rare packages
> >>> that use -Werror than pointing at potential miscompilations.
> >>>
> >>> >From a distribution point of view, a package build with -Werror by
> >>> default is arguably a bug since this frequently breaks when something
> >>> is changed (usually the compiler version).
> >>>
> >>> -Og is better suited than the -O that was previously used for debugging,
> >>> but are we talking about debug builds or production builds?
> >>> If users would be using DEBUG_OPTIMIZATION in production builds that
> >>
> >> Thanks Adrian and Khem's response!
> >> We indeed don't use DEBUG_OPTIMIZATION in production build.
> >>
> >> But still comes question: how to silence gcc-sanitizers build failure
> >> when debug build enabled?
> >>
> >> Thanks,
> >>
> >>> would be wrong - this will always be a mostly untested situation
> >>> with an increased probability of hitting bugs noone else has seen
> >>> before.
> >
> > disable warning as errors.
>
> Hi Khem,
>
> I don't quite get what you mean. Disable warning as errors?
>
> As https://gcc.gnu.org/ml/gcc-patches/2019-04/msg00315.html, gcc
> upstream thinks the build error is meaningless when compile
> gcc-sanitizers with -Og and suggests not use -Og to compile for
> gcc-sanitizers.
>
> So I send out the patch to add the workaround [DEBUG_OPTIMIZATION_append
> = " -Wno-error"] to silence the error when debug build is enabled for
> gcc-sanitizers.
> If the workaround isn't suitable, then how to silence the
> -Werror=maybe-uninitialized issue build error when debug build enabled?

I was meaning to say that remove -Werror from cmdline completely

>
> Thanks,
>
> >
> >>>
> >>> cu
> >>> Adrian
> >>>
> >

Re: [PATCH v3] gcc-sanitizers: fix -Werror=maybe-uninitialized issue

[Yu, Mingli]

On 2019年04月18日 01:14, Khem Raj wrote:
> On Wed, Apr 17, 2019 at 12:45 AM Yu, Mingli <mingli.yu@windriver.com> wrote:
>>
>>
>>
>> On 2019年04月17日 02:00, Khem Raj wrote:
>>> On Tue, Apr 16, 2019 at 1:40 AM Yu, Mingli <mingli.yu@windriver.com> wrote:
>>>>
>>>>
>>>>
>>>> On 2019年04月16日 00:21, Adrian Bunk wrote:
>>>>> On Mon, Apr 15, 2019 at 07:19:13AM -0700, Khem Raj wrote:
>>>>>>
>>>>>> What are you trying to convey ? That’s what I mentioned before I began my
>>>>>> reply however to reiterate my point was if a package is not usually built
>>>>>> and tested with this combination which is evident because it fails to build
>>>>>> then how good would it be if we fix this error especially complex packages
>>>>>> like compilers so is it worth to fix them or disable Og for them
>>>>>
>>>>> Packages that usually get built and tested with -Og should be pretty rare,
>>>>> and these specific build failures are better at finding the rare packages
>>>>> that use -Werror than pointing at potential miscompilations.
>>>>>
>>>>> >From a distribution point of view, a package build with -Werror by
>>>>> default is arguably a bug since this frequently breaks when something
>>>>> is changed (usually the compiler version).
>>>>>
>>>>> -Og is better suited than the -O that was previously used for debugging,
>>>>> but are we talking about debug builds or production builds?
>>>>> If users would be using DEBUG_OPTIMIZATION in production builds that
>>>>
>>>> Thanks Adrian and Khem's response!
>>>> We indeed don't use DEBUG_OPTIMIZATION in production build.
>>>>
>>>> But still comes question: how to silence gcc-sanitizers build failure
>>>> when debug build enabled?
>>>>
>>>> Thanks,
>>>>
>>>>> would be wrong - this will always be a mostly untested situation
>>>>> with an increased probability of hitting bugs noone else has seen
>>>>> before.
>>>
>>> disable warning as errors.
>>
>> Hi Khem,
>>
>> I don't quite get what you mean. Disable warning as errors?
>>
>> As https://gcc.gnu.org/ml/gcc-patches/2019-04/msg00315.html, gcc
>> upstream thinks the build error is meaningless when compile
>> gcc-sanitizers with -Og and suggests not use -Og to compile for
>> gcc-sanitizers.
>>
>> So I send out the patch to add the workaround [DEBUG_OPTIMIZATION_append
>> = " -Wno-error"] to silence the error when debug build is enabled for
>> gcc-sanitizers.
>> If the workaround isn't suitable, then how to silence the
>> -Werror=maybe-uninitialized issue build error when debug build enabled?
>
> I was meaning to say that remove -Werror from cmdline completely

Thanks Khem! So this is what we did currently now in V3 patch.

Hi RP,
So any comments here/

Thanks,

>
>>
>> Thanks,
>>
>>>
>>>>>
>>>>> cu
>>>>> Adrian
>>>>>
>>>
>

[PATCH v4] gcc-sanitizers: fix -Werror=maybe-uninitialized issue

[mingli.yu]

From: Mingli Yu <Mingli.Yu@windriver.com>

When DEBUG_BUILD = "1" added in local.conf, there
comes below build error when "bitbake gcc-sanitizers":
| ./../../../../../../../../work-shared/gcc-8.3.0-r0/gcc-8.3.0/libsanitizer/libbacktrace/../../libbacktrace/elf.c: In function 'elf_is_symlink':
| ../../../../../../../../../work-shared/gcc-8.3.0-r0/gcc-8.3.0/libsanitizer/libbacktrace/../../libbacktrace/elf.c:772:21: error: 'st.st_mode' may be used uninitialized in this function [-Werror=maybe-uninitialized]
|   return S_ISLNK (st.st_mode);

After commit[16643b0322 bitbake.conf: Use -Og in DEBUG_OPTIMIZATION]
introduced, "-Og" added to compiler when debug
build enabled.

Per https://gcc.gnu.org/ml/gcc-patches/2019-04/msg00315.html,
the gcc upstream thinks the warning is a false
positive and suggests to use -O2 rather than -Og
or -O1 when compiling that file, so pass -Wno-error
to compiler when -Og is used to silence the error.

Signed-off-by: Mingli Yu <Mingli.Yu@windriver.com>
---
 meta/recipes-devtools/gcc/gcc-sanitizers.inc | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/meta/recipes-devtools/gcc/gcc-sanitizers.inc b/meta/recipes-devtools/gcc/gcc-sanitizers.inc
index e5e8452..8b1d1c9 100644
--- a/meta/recipes-devtools/gcc/gcc-sanitizers.inc
+++ b/meta/recipes-devtools/gcc/gcc-sanitizers.inc
@@ -45,6 +45,9 @@ INHIBIT_DEFAULT_DEPS = "1"
 ALLOW_EMPTY_${PN} = "1"
 DEPENDS = "gcc-runtime virtual/${TARGET_PREFIX}gcc"
 
+# used to fix ../../../../../../../../../work-shared/gcc-8.3.0-r0/gcc-8.3.0/libsanitizer/libbacktrace/../../libbacktrace/elf.c:772:21: error: 'st.st_mode' may be used uninitialized in this function [-Werror=maybe-uninitialized]
+DEBUG_OPTIMIZATION_append = " -Wno-error"
+
 BBCLASSEXTEND = "nativesdk"
 
 PACKAGES = "${PN} ${PN}-dbg"
-- 
2.7.4