From: Tom Tromey <tom@tromey.com>
To: gdb-patches@sourceware.org
Cc: Tom Tromey <tom@tromey.com>
Subject: [PATCH v2 3/6] Cast to bfd_vma in arm-tdep.c
Date: Tue, 25 Feb 2020 22:22:00 -0000 [thread overview]
Message-ID: <20200225222243.8260-4-tom@tromey.com> (raw)
In-Reply-To: <20200225222243.8260-1-tom@tromey.com>
Some arm-tdep.c data structures use a bfd_vma. A couple of spots will
warn about an implicit narrowing cast when building a gdb where
CORE_ADDR is 64-bit but bfd_vma is 32-bit.
This patch silences these warnings by introducing an explicit cast.
This seemed both simplest and correct.
2020-02-25 Tom Tromey <tom@tromey.com>
* arm-tdep.c (map_key, arm_find_exidx_entry): Cast to bfd_vma.
---
gdb/ChangeLog | 4 ++++
gdb/arm-tdep.c | 5 +++--
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/gdb/arm-tdep.c b/gdb/arm-tdep.c
index 175c5b956e7..d395c7f7b75 100644
--- a/gdb/arm-tdep.c
+++ b/gdb/arm-tdep.c
@@ -366,7 +366,7 @@ arm_find_mapping_symbol (CORE_ADDR memaddr, CORE_ADDR *start)
}
struct arm_mapping_symbol map_key
- = { memaddr - obj_section_addr (sec), 0 };
+ = { (bfd_vma) (memaddr - obj_section_addr (sec)), 0 };
arm_mapping_symbol_vec::const_iterator it
= std::lower_bound (map.begin (), map.end (), map_key);
@@ -2246,7 +2246,8 @@ arm_find_exidx_entry (CORE_ADDR memaddr, CORE_ADDR *start)
if (sec != NULL)
{
struct arm_exidx_data *data;
- struct arm_exidx_entry map_key = { memaddr - obj_section_addr (sec), 0 };
+ struct arm_exidx_entry map_key
+ = { (bfd_vma) (memaddr - obj_section_addr (sec)), 0 };
data = arm_exidx_data_key.get (sec->objfile->obfd);
if (data != NULL)
--
2.17.2
next prev parent reply other threads:[~2020-02-25 22:22 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-25 22:22 [PATCH v2 0/6] Change gdbserver to use existing gdbsupport Tom Tromey
2020-02-25 22:22 ` [PATCH v2 2/6] Don't use sprintf_vma for CORE_ADDR Tom Tromey
2020-02-25 22:22 ` [PATCH v2 6/6] Change gdbserver to use existing gdbsupport Tom Tromey
2020-02-25 22:22 ` [PATCH v2 4/6] Fix gdbserver build when intl already built Tom Tromey
2020-02-25 22:22 ` [PATCH v2 5/6] Change gdbsupport not to rely on BFD Tom Tromey
2020-02-25 22:22 ` Tom Tromey [this message]
2020-03-11 3:38 ` [PATCH v2 3/6] Cast to bfd_vma in arm-tdep.c Simon Marchi
2020-03-12 17:58 ` Tom Tromey
2020-03-12 18:05 ` Simon Marchi
2020-03-12 19:35 ` Tom Tromey
2020-02-25 22:22 ` [PATCH v2 1/6] Fix CORE_ADDR size assertion in symfile-mem.c Tom Tromey
2020-03-11 0:30 ` [PATCH v2 0/6] Change gdbserver to use existing gdbsupport Tom Tromey
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=20200225222243.8260-4-tom@tromey.com \
--to=tom@tromey.com \
--cc=gdb-patches@sourceware.org \
/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).