From: Sergio Durigan Junior <sergiodj@redhat.com>
To: GDB Patches <gdb-patches@sourceware.org>
Cc: Pedro Alves <palves@redhat.com>,
Sergio Durigan Junior <sergiodj@redhat.com>
Subject: [PATCH] Silence GCC "uninitialized" warning on minsyms.c:lookup_minimal_symbol_by_pc_section
Date: Mon, 18 Jun 2018 20:26:00 -0000 [thread overview]
Message-ID: <20180618202634.10452-1-sergiodj@redhat.com> (raw)
In-Reply-To: <20180325191943.8246-12-palves@redhat.com>
Commit 20944a6e20324cd897bf6c4c5fd20ef7224dacaa ("Fix stepping past
GNU ifunc resolvers (introduce lookup_msym_prefer)") introduced a new
way to determine the 'want_type' variable on
minsyms.c:lookup_minimal_symbol_by_pc_section. Because the
'lookup_msym_prefer' has a default value, we know that 'want_type'
will always be initialized. However, GCC is complaining that the
variable can be used uninitialized in the function:
../../gdb/minsyms.c: In function 'bound_minimal_symbol lookup_minimal_symbol_by_pc_section(CORE_ADDR, obj_section*, lookup_msym_prefer)':
../../gdb/minsyms.c:825:40: warning: 'want_type' may be used uninitialized in this function [-Wmaybe-uninitialized]
&& MSYMBOL_TYPE (&msymbol[hi]) != want_type
(This is with gcc-8.1.1-1.fc29.x86_64).
This patch fixes it by initializing 'want_type' with 'mst_text', which
is the same default value that is passed in the 'lookup_msym_prefer'
variable.
Even though this can be considered an obvious patch, I'm sending it
for approval.
gdb/ChangeLog:
2018-06-18 Sergio Durigan Junior <sergiodj@redhat.com>
* minsyms.c (lookup_minimal_symbol_by_pc_section): Initialize
'want_type' to silence GCC warning.
---
gdb/ChangeLog | 5 +++++
gdb/minsyms.c | 2 +-
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/gdb/ChangeLog b/gdb/ChangeLog
index 4fc6cf5446..5cf9da8e56 100644
--- a/gdb/ChangeLog
+++ b/gdb/ChangeLog
@@ -1,3 +1,8 @@
+2018-06-18 Sergio Durigan Junior <sergiodj@redhat.com>
+
+ * minsyms.c (lookup_minimal_symbol_by_pc_section): Initialize
+ 'want_type' to silence GCC warning.
+
2018-06-18 Tom Tromey <tom@tromey.com>
* solib-aix.c (solib_aix_get_section_offsets): Return
diff --git a/gdb/minsyms.c b/gdb/minsyms.c
index 4882e58ee4..c9d89dc171 100644
--- a/gdb/minsyms.c
+++ b/gdb/minsyms.c
@@ -683,7 +683,7 @@ lookup_minimal_symbol_by_pc_section (CORE_ADDR pc_in, struct obj_section *sectio
struct minimal_symbol *best_symbol = NULL;
struct objfile *best_objfile = NULL;
struct bound_minimal_symbol result;
- enum minimal_symbol_type want_type;
+ enum minimal_symbol_type want_type = mst_text;
if (section == NULL)
{
--
2.14.3
next prev parent reply other threads:[~2018-06-18 20:26 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-25 19:19 [PATCH v2 00/15] Fixing GNU ifunc support Pedro Alves
2018-03-25 19:19 ` [PATCH v2 07/15] Breakpoints, don't skip prologue of ifunc resolvers with debug info Pedro Alves
2018-03-25 19:19 ` [PATCH v2 11/15] Fix stepping past GNU ifunc resolvers (introduce lookup_msym_prefer) Pedro Alves
2018-06-18 20:26 ` Sergio Durigan Junior [this message]
2018-06-19 15:22 ` [PATCH] Silence GCC "uninitialized" warning on minsyms.c:lookup_minimal_symbol_by_pc_section Pedro Alves
2018-06-19 16:55 ` Sergio Durigan Junior
2018-06-19 18:47 ` Tom Tromey
2018-03-25 19:19 ` [PATCH v2 12/15] For PPC64/ELFv1: Introduce mst_data_gnu_ifunc Pedro Alves
2018-03-25 19:19 ` [PATCH v2 03/15] Calling ifunc functions when target has no debug info but resolver has Pedro Alves
2018-04-01 4:22 ` Simon Marchi
2018-04-10 21:48 ` Pedro Alves
2018-04-10 21:54 ` Pedro Alves
2018-03-25 19:19 ` [PATCH v2 08/15] Eliminate find_pc_partial_function_gnu_ifunc Pedro Alves
2018-03-25 19:19 ` [PATCH v2 15/15] Fix resolving GNU ifunc bp locations when inferior runs resolver Pedro Alves
2018-03-25 19:19 ` [PATCH v2 05/15] Fix elf_gnu_ifunc_resolve_by_got buglet Pedro Alves
2018-04-01 4:32 ` Simon Marchi
2018-04-10 21:52 ` Pedro Alves
2018-03-25 19:19 ` [PATCH v2 02/15] Fix calling ifunc functions when resolver has debug info and different name Pedro Alves
2018-04-01 3:44 ` Simon Marchi
2018-04-10 21:20 ` Pedro Alves
2018-03-25 19:19 ` [PATCH v2 01/15] Fix breakpoints in ifunc after inferior resolved it (@got.plt symbol creation) Pedro Alves
2018-04-01 3:35 ` Simon Marchi
2018-04-10 21:20 ` Pedro Alves
2018-04-14 16:36 ` Simon Marchi
2018-03-25 19:25 ` [PATCH v2 04/15] Calling ifunc functions when resolver has debug info, user symbol same name Pedro Alves
2018-03-25 19:25 ` [PATCH v2 09/15] Factor out minsym_found/find_function_start_sal overload Pedro Alves
2018-03-25 19:28 ` [PATCH v2 14/15] Extend GNU ifunc testcases Pedro Alves
2018-03-25 19:29 ` [PATCH v2 10/15] For PPC64: elf_gnu_ifunc_record_cache: handle plt symbols in .text section Pedro Alves
2018-03-25 19:29 ` [PATCH v2 13/15] PPC64: always make synthetic .text symbols for GNU ifunc symbols Pedro Alves
2018-03-25 19:33 ` Pedro Alves
2018-03-26 7:54 ` Alan Modra
2018-03-25 19:29 ` [PATCH v2 06/15] Fix setting breakpoints on ifunc functions after they're already resolved Pedro Alves
2018-04-26 12:23 ` [PATCH v2 00/15] Fixing GNU ifunc support Pedro Alves
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180618202634.10452-1-sergiodj@redhat.com \
--to=sergiodj@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=palves@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).