public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Peter Bergner <bergner@vnet.ibm.com>
To: Segher Boessenkool <segher@kernel.crashing.org>
Cc: GCC Patches <gcc-patches@gcc.gnu.org>,
	       Tulio Magno Quites Machado Filho
	<tuliom@linux.vnet.ibm.com>
Subject: Re: [PATCH, rs6000] Add support to __builtin_cpu_supports() for two new HWCAP2 bits
Date: Fri, 30 Jun 2017 16:53:00 -0000	[thread overview]
Message-ID: <d4dbbe2c-00ca-e350-2fa0-cbbc173d9b60@vnet.ibm.com> (raw)
In-Reply-To: <74c6827e-fa3c-63da-b386-0b49098fab13@vnet.ibm.com>

Segher, any response to my findings below about whether we should
try and share header files with GLIBC?

Peter


On 6/27/17 1:06 PM, Peter Bergner wrote:
> On 6/27/17 11:07 AM, Segher Boessenkool wrote:
>> Not use an installed header, that's not what I'm asking.  Share the
>> source file, i.e., just copy it over from the glibc source tree (it
>> should probably hold the master copy).  Fewer typos, cannot forget to
>> update some entry, etc.
> 
> So the glibc file is:
> 
>   sysdeps/powerpc/bits/hwcap.h
> 
> which contains only the #define PPC_FEATURE[2]_* definitions.
> The GCC file is:
> 
>   gcc/config/rs6000/ppc-auxv.h
> 
> and contains the same #define's as hwcap.h above, plus the additional
> #defines's:
> 
> /* The PLATFORM value stored in the TCB is offset by _DL_FIRST_PLATFORM.  */
> #define _DL_FIRST_PLATFORM             32
> 
> /* AT_PLATFORM bits.  These must match the values defined in GLIBC. */
> #define PPC_PLATFORM_POWER4            0
> #define PPC_PLATFORM_PPC970            1
> #define PPC_PLATFORM_POWER5            2
> ...
> 
> which match values in glibc's sysdeps/powerpc/dl-procinfo.h, but that
> file contains a lot more than just the defines that we (GCC) doesn't
> want or need.
> 
> ppc-auxv.h also contains the following helper macros that calculate the
> fixed offsets to the TCB slots that glibc initializes, but glibc has
> access to the structs that the slows live in, so they don't need these
> helper macros and hence don't have them:
> 
> /* Thread Control Block (TCB) offsets of the AT_PLATFORM, AT_HWCAP and
>    AT_HWCAP2 values.  These must match the values defined in GLIBC.  */
> #define TCB_PLATFORM_OFFSET ((TARGET_64BIT) ? -28764 : -28724)
> #define TCB_HWCAP_BASE_OFFSET ((TARGET_64BIT) ? -28776 : -28736)
> #define TCB_HWCAP1_OFFSET \
>   ((BYTES_BIG_ENDIAN) ? TCB_HWCAP_BASE_OFFSET : TCB_HWCAP_BASE_OFFSET+4)
> #define TCB_HWCAP2_OFFSET \
>   ((BYTES_BIG_ENDIAN) ? TCB_HWCAP_BASE_OFFSET+4 : TCB_HWCAP_BASE_OFFSET)
> #define TCB_HWCAP_OFFSET(ID) \
>   (((ID) == 0) ? TCB_HWCAP1_OFFSET : TCB_HWCAP2_OFFSET)
> 
> These are only used in rs6000.c, so I could move them there.
> 
> So given the above, how do we want to handle this?  If we were to copy a
> header file(s) over from glibc, are we able to modify it in the process?
> Ie, to remove the parts we don't need like hwcap.h's use of:
> 
>   #if !defined(_SYS_AUXV_H) && !defined(_SYSDEPS_SYSDEP_H)
>   # error "Never include <bits/hwcap.h> directly; use <sys/auxv.h> instead."
>   #endif
> 
> which would trigger for our use of it.  And also to remove unneeded code from
> dl-procinfo.h, since we only want the #defines.
> 
> Peter
> 
> 

  reply	other threads:[~2017-06-30 16:53 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-27  3:34 Peter Bergner
2017-06-27 15:52 ` Segher Boessenkool
2017-06-27 15:56   ` Peter Bergner
2017-06-27 16:08     ` Segher Boessenkool
2017-06-27 16:44       ` Peter Bergner
2017-06-27 18:06       ` Peter Bergner
2017-06-30 16:53         ` Peter Bergner [this message]
2017-06-30 23:45           ` Segher Boessenkool
2017-07-05 20:27             ` Tulio Magno Quites Machado Filho
2017-07-29 21:54   ` Peter Bergner

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=d4dbbe2c-00ca-e350-2fa0-cbbc173d9b60@vnet.ibm.com \
    --to=bergner@vnet.ibm.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=segher@kernel.crashing.org \
    --cc=tuliom@linux.vnet.ibm.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).