From: "Philippe Mathieu-Daudé" <philmd@linaro.org>
To: Brian Cain <bcain@quicinc.com>,
"richard.henderson@linaro.org" <richard.henderson@linaro.org>,
"anjo@rev.ng" <anjo@rev.ng>
Cc: "armbru@redhat.com" <armbru@redhat.com>,
"peter.maydell@linaro.org" <peter.maydell@linaro.org>,
"Matheus Bernardino (QUIC)" <quic_mathbern@quicinc.com>,
"stefanha@redhat.com" <stefanha@redhat.com>,
"ale@rev.ng" <ale@rev.ng>,
"Marco Liebel (QUIC)" <quic_mliebel@quicinc.com>,
"ltaylorsimpson@gmail.com" <ltaylorsimpson@gmail.com>,
"Thomas Huth" <thuth@redhat.com>,
"Daniel P. Berrangé" <berrange@redhat.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [PATCH v2 3/3] target/hexagon: avoid shadowing globals
Date: Tue, 10 Oct 2023 07:22:31 +0200 [thread overview]
Message-ID: <0aa445c4-d39d-e28a-6bb0-00f7b9f12bb0@linaro.org> (raw)
In-Reply-To: <BN7PR02MB4194900078A1AA6E067FE20FB8CEA@BN7PR02MB4194.namprd02.prod.outlook.com>
On 9/10/23 22:53, Brian Cain wrote:
>> On 9/10/23 08:09, Philippe Mathieu-Daudé wrote:
>>> On 6/10/23 00:22, Brian Cain wrote:
>>>> The typedef `vaddr` is shadowed by `vaddr` identifiers, so we rename the
>>>> identifiers to avoid shadowing the type name.
>>>
>>> This one surprises me, since we have other occurences:
>>>
>>> include/exec/memory.h:751:bool memory_get_xlat_addr(IOMMUTLBEntry
>>> *iotlb, void **vaddr,
>>> include/qemu/plugin.h:199:void qemu_plugin_vcpu_mem_cb(CPUState
>>> *cpu, uint64_t vaddr,
>>> target/arm/internals.h:643:G_NORETURN void
>>> arm_cpu_do_unaligned_access(CPUState *cs, vaddr vaddr,
>>> target/i386/tcg/helper-tcg.h:70:G_NORETURN void
>>> handle_unaligned_access(CPUX86State *env, vaddr vaddr,
>>> ...
>>>
>>> $ git grep -w vaddr, | wc -l
>>> 207
>>>
>>> What is the error/warning like?
>>
>> OK I could reproduce, I suppose you are building with Clang which
>> doesn't support shadow-local so you get global warnings too (as
>> mentioned in this patch subject...):
>
> No -- I generally build with gcc and only double-check the clang results to make sure I don't see any new failures there.
>
> But I've not tested "-Wshadow" with clang yet. I found these by adding "-Wshadow=global" to "-Wshadow=local". I thought it might be useful to address these too while we're here.
>
>> In file included from ../../gdbstub/trace.h:1,
>> from ../../gdbstub/softmmu.c:30:
>> trace/trace-gdbstub.h: In function '_nocheck__trace_gdbstub_hit_watchpoint':
>> trace/trace-gdbstub.h:903:106: error: declaration of 'vaddr' shadows a
>> global declaration [-Werror=shadow]
>> 903 | static inline void _nocheck__trace_gdbstub_hit_watchpoint(const
>> char * type, int cpu_gdb_index, uint64_t vaddr)
>> |
>> ~~~~~~~~~^~~~~
>> In file included from include/sysemu/accel-ops.h:13,
>> from include/sysemu/cpus.h:4,
>> from ../../gdbstub/softmmu.c:21:
>> include/exec/cpu-common.h:21:18: note: shadowed declaration is here
>> 21 | typedef uint64_t vaddr;
>> | ^~~~~
>> trace/trace-gdbstub.h: In function 'trace_gdbstub_hit_watchpoint':
>> trace/trace-gdbstub.h:923:96: error: declaration of 'vaddr' shadows a
>> global declaration [-Werror=shadow]
>> 923 | static inline void trace_gdbstub_hit_watchpoint(const char *
>> type, int cpu_gdb_index, uint64_t vaddr)
>> |
>> ~~~~~~~~~^~~~~
>> include/exec/cpu-common.h:21:18: note: shadowed declaration is here
>> 21 | typedef uint64_t vaddr;
>> | ^~~~~
If we have to clean that for -Wshadow=global, I'm tempted to rename
the typedef as 'vaddr_t' and keep the 'vaddr' variable names.
Richard, Anton, what do you think?
>> Clang users got confused by this, IIUC Markus and Thomas idea is
>> to only enable these warnings for GCC, enforcing them for Clang
>> users via CI (until Clang get this option supported). Personally
>> I'd rather enable the warning once for all, waiting for Clang
>> support (or clean/enable global shadowing for GCC too).
>
> Hopefully it's helpful or at least benign if we address the shadowed globals under target/hexagon/ for now, even if "-Wshadow=global" is not enabled.
>
>> See this thread:
>> https://lore.kernel.org/qemu-devel/11abc551-188e-85c0-fe55-
>> b2b58d35105d@redhat.com/
>>
>> Regards,
>>
>> Phil.
next prev parent reply other threads:[~2023-10-10 5:23 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-05 22:22 [PATCH v2 0/3] hexagon: GETPC() and shadowing fixes Brian Cain
2023-10-05 22:22 ` [PATCH v2 1/3] target/hexagon: move GETPC() calls to top level helpers Brian Cain
2023-10-05 22:22 ` [PATCH v2 2/3] target/hexagon: fix some occurrences of -Wshadow=local Brian Cain
2023-10-06 5:49 ` Philippe Mathieu-Daudé
2023-10-06 14:59 ` ltaylorsimpson
2023-10-05 22:22 ` [PATCH v2 3/3] target/hexagon: avoid shadowing globals Brian Cain
2023-10-06 16:00 ` ltaylorsimpson
2023-10-08 13:49 ` Brian Cain
2023-10-09 18:59 ` ltaylorsimpson
2023-10-09 6:09 ` Philippe Mathieu-Daudé
2023-10-09 6:43 ` Philippe Mathieu-Daudé
2023-10-09 20:53 ` Brian Cain
2023-10-10 5:22 ` Philippe Mathieu-Daudé [this message]
2023-10-10 6:04 ` Markus Armbruster
2023-10-10 7:34 ` Philippe Mathieu-Daudé
2023-10-10 9:10 ` Thomas Huth
2023-10-18 3:11 ` Brian Cain
2023-10-10 4:57 ` Markus Armbruster
2023-10-06 9:00 ` [PATCH v2 0/3] hexagon: GETPC() and shadowing fixes Markus Armbruster
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=0aa445c4-d39d-e28a-6bb0-00f7b9f12bb0@linaro.org \
--to=philmd@linaro.org \
--cc=ale@rev.ng \
--cc=anjo@rev.ng \
--cc=armbru@redhat.com \
--cc=bcain@quicinc.com \
--cc=berrange@redhat.com \
--cc=ltaylorsimpson@gmail.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=quic_mathbern@quicinc.com \
--cc=quic_mliebel@quicinc.com \
--cc=richard.henderson@linaro.org \
--cc=stefanha@redhat.com \
--cc=thuth@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 NNTP newsgroup(s).