From: "Joseph S. Myers" <joseph@codesourcery.com>
To: Andrew Pinski <pinskia@gmail.com>
Cc: Andrew Stubbs <ams@codesourcery.com>,
"libc-ports@sourceware.org" <libc-ports@sourceware.org>
Subject: Re: [PATCH] PAGE_SIZE definition for MIPS XLP
Date: Tue, 19 Nov 2013 14:57:00 -0000 [thread overview]
Message-ID: <Pine.LNX.4.64.1311191341280.28227@digraph.polyomino.org.uk> (raw)
In-Reply-To: <CA+=Sn1nSOoXDFzmCbBEREJiQCxg_GoPXf6QNBS5UFRmQMVng8A@mail.gmail.com>
On Mon, 18 Nov 2013, Andrew Pinski wrote:
> I think my attached patch is better way of fixing this issue which
> just deletes them rather than special casing them.
Deleting (for both MIPS and MicroBlaze) would indeed be better if the API
for these symbols is that they should only be defined if the kernel page
size is constant.
Someone still needs to look into the API for all these symbols and write a
proper explanation of how they are used (outside of glibc) and what
requirements apply to them. It's not clear whether it's right to remove
the whole block from PAGE_SHIFT to HOST_STACK_END_ADDR, or only a subset
that directly depend on the page size; that may depend on whether the
other symbols are ever used in a context not also depending on PAGE_SIZE
(are they only for BFD's trad-core?). Given such an explanation, we can
better judge a removal patch. I don't want "this causes problems, so
remove it"; I want "this is incorrect because (explanation of the
interface), so removing it is correct".
Note that IA64 confuses things by defining a subset of the macros,
including defining NBPG to PAGE_SIZE despite that header not defining
PAGE_SIZE.
The patch does of course need a proper bug number from glibc Bugzilla (as
I noted, either a bug needs filing for all affected architectures, or
separate bugs for each architecture, in accordance with glibc practice
that if fixing a bug that was user-visible in a release then you also file
it in Bugzilla to make searches of fixed bugs more useful) and the path in
the ChangeLog entry given without the initial ports/, as appropriate for
ChangeLog.mips.
--
Joseph S. Myers
joseph@codesourcery.com
next prev parent reply other threads:[~2013-11-19 13:50 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-18 12:51 Andrew Stubbs
2013-11-18 13:42 ` Andreas Schwab
2013-11-19 20:56 ` Maciej W. Rozycki
2013-11-18 13:45 ` Joseph S. Myers
2013-11-18 18:21 ` Joseph S. Myers
2013-11-19 3:28 ` Andrew Pinski
2013-11-19 14:57 ` Joseph S. Myers [this message]
2013-11-19 20:19 ` Andrew Stubbs
2013-11-20 19:57 ` Maciej W. Rozycki
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=Pine.LNX.4.64.1311191341280.28227@digraph.polyomino.org.uk \
--to=joseph@codesourcery.com \
--cc=ams@codesourcery.com \
--cc=libc-ports@sourceware.org \
--cc=pinskia@gmail.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).