From: Jeff Epler <jepler@unpythonic.net>
To: Chen Gang <gang.chen.5i5j@gmail.com>
Cc: cmetcalf@tilera.com,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] arch: tile: kernel: kgdb.c: Use memcpy() instead of pointer copy one by one
Date: Wed, 12 Nov 2014 13:29:29 -0600 [thread overview]
Message-ID: <20141112192929.GC53560@unpythonic.net> (raw)
In-Reply-To: <5463800C.8050404@gmail.com>
On Wed, Nov 12, 2014 at 11:43:08PM +0800, Chen Gang wrote:
> > (I assume the
> > compiler could do things like replace an intended load from memory with
> > a constant load or even no load at all)
> >
>
> Excuse me, my English is not quite well, I can not understand what you
> said above. (If necessary, please help provide more details for it).
I am concerned that writing regs[TREG_TP] is "undefined behavior"
according to the C standard.
This expression is equivalent to *(regs + TREG_TP). The expression
(regs + TREG_TP) does not result in a pointer to any element of regs[],
so dereferencing it is undefined behavior. (Source: C99 draft standard
WG14/N1256, annex J.2, "[The behavior is undefined if t]he operand of
the unary * operator has an invalid value")
That is why the compiler showed the original diagnostic, but the same
logic that made the loop's behavior undefined also makes the expression
regs[TREG_TP] undefined whereever it appears.
None of this is a specific problem with your proposed patch. Rather, it
is a suggestion that the whole structure's design needs to be revisited
in light of compilers beginning to notice that regs[TREG_TP] is
undefined behavior and change their generated code as a result.
Unfortunately it looks like this header is also a part of the userspace
API, so it can't simply be changed just in case all in-kernel uses are
changed.
Jeff
next prev parent reply other threads:[~2014-11-12 19:29 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-01 13:17 [PATCH] arch: tile: kernel: kgdb.c: Use memcpy() instead of pointer copy one by one Chen Gang
2014-11-12 2:11 ` Chen Gang
2014-11-12 13:27 ` Jeff Epler
2014-11-12 15:43 ` Chen Gang
2014-11-12 19:29 ` Jeff Epler [this message]
2014-11-12 20:15 ` Chris Metcalf
-- strict thread matches above, loose matches on Subject: below --
2014-11-13 0:08 Chen Gang
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=20141112192929.GC53560@unpythonic.net \
--to=jepler@unpythonic.net \
--cc=cmetcalf@tilera.com \
--cc=gang.chen.5i5j@gmail.com \
--cc=linux-kernel@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.