This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: [PATCH][GCC][front-end][build-machinery][opt-framework] Allow setting of stack-clash via configure options. [Patch (4/6)]


Hi Jeff,

> -----Original Message-----
> From: Jeff Law <law@redhat.com>
> Sent: Thursday, July 19, 2018 18:32
> To: Tamar Christina <Tamar.Christina@arm.com>
> Cc: gcc-patches@gcc.gnu.org; nd <nd@arm.com>;
> joseph@codesourcery.com; bonzini@gnu.org; dj@redhat.com;
> neroden@gcc.gnu.org; aoliva@redhat.com; Ralf.Wildenhues@gmx.de
> Subject: Re: [PATCH][GCC][front-end][build-machinery][opt-framework]
> Allow setting of stack-clash via configure options. [Patch (4/6)]
> 
> On 07/19/2018 06:55 AM, Tamar Christina wrote:
> >>>
> >>> What's the purpose of including auto-host in params-list and
> >>> params-options?  It seems like you're putting a property of the
> >>> target (guard size) into the wrong place (auto-host.h).
> >>>
> >>
> >> The reason for this is because there's a test
> >> gcc.dg/params/blocksort-part.c that uses these params-options to
> >> generate test cases to perform parameter validation. However because
> >> now the params.def file can contain a CPP macro these would then fail.
> >>
> >> CPP is already called to create params-options and params-list so the
> >> easiest way to fix this test was just to include auto-host which
> >> would get it the values from configure.
> >>
> >> This test is probably not needed anymore after my second patch series
> >> as parameters are validated by the front-end now, so they can never
> >> go out of range.
> Right, but I don't immediately see a way to avoid the test.  ie, it just walks
> down everything in params.options and except for a couple exceptional
> values the test gets run.
> 
> I wonder if all this is an indication that having CPP constants in the options
> isn't going to work well as we're mixing the distinction between host/target.
> 
> 
> >>
> >>> It's also a bit unclear to me why this is necessary at all.  Are we
> >>> planning to support both the 4k and 64k guards?  My goal (once the
> >>> guard was configurable) was never for supporting multiple sizes on a
> >>> target but instead to allow experimentation to find the right default.
> >>>
> >
> > Having talked to people I believe we do need to support both 4k and 64k
> guards.
> > For the Linux/Glibc world it wouldn't matter much, either 4 or 64k would do,
> though Glibc has settled on 64k pages.
> >
> > However other systems like (open/free)BSD or musl based systems do not
> > want 64k pages but want 4k ones.  So we're ending up having to support
> both as a compromise.
> Understood.  Thanks for verifying.  I wonder if we could just bury this entirely
> in the aarch64 config files and not expose the default into params.def?
> 

Burying it in config.gcc isn't ideal because if your C runtime is configurable (like uClibc) it means you
have to go and modify this file every time you change something. If the argument is 
against having these defines in the params and not the configure flag itself then I can just
have an aarch64 specific configure flag and just use the created define directly in the AArch64 back-end.

Would that be an acceptable solution?

Thanks,
Tamar

> jeff

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]