public inbox for libc-ports@sourceware.org
 help / color / mirror / Atom feed
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

  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).