Re: GTY / gengtype question - adding a new header file

[Richard Sandiford]

"Steve Ellcey "  writes:
> I have a question about gengtype and GTY.  I was looking at adding some
> code to mips.c and it occurred to me that that file was getting very
> large (19873 lines).  So I wanted to add a new .c file instead but that
> file needed some types that were defined in mips.c and not in a header file.
> Specifically it needed the MIPS specific machine_function structure that
> is defined in mips.c with:
>
> struct GTY(())  machine_function {
>
> I think I could just move this to mips.h and things would be fine but
> I didn't want to do that because mips.h is included in tm.h and is visible
> to the generic GCC code.  Currently machine_function is not visible to the
> generic GCC code and so I wanted to put machine_function in a header file
> that could only be seen/used by mips specific code.  So I created
> mips-private.h and added it to extra_headers in config.gcc.
>
> The problem is that if I include mips-private.h in mips.c instead of
> having the actual definition of machine_function in mips.c then my
> build fails and I think it is due to how and where gengtype scans for GTY
> uses.
>
> I couldn't find an example of a platform that has a machine specific header
> file that was not visible to the generic GCC code and that has GTY types
> in it so I am not sure what I need to do to get gengtype to scan
> mips-private.h or if this is even possible (or wise).

config.gcc would need to add mips-private.h to target_gtfiles.

I'm not sure splitting the file is a good idea though.  At the moment
the definitions of all target hooks must be visible to a single TU.
Either you'd need to keep all the hooks in one .c file (leading
to an artificial split IMO) or you'd need declare some of them
in the private header.  Declaring them in the header file would only be
consistent if the targetm definition was in its own file (so that _every_
hook had a prototype in the private header).  That seems like unnecessary
work though.

I'm also a bit worried that if more ports go down this path, each port
will have its own conventions for what goes where.  That just makes
life harder for people who want to change a target interface and need
to touch all targets.

We already have that problem to some extent when it comes to whether
targetm is initialised at the head of the file, using forward static
declarations, or at the end, with no need for forward declarations.
As Joseph said in old post, if we switched all targets to using the
latter form, converting macros to hooks would become almost automatic.
Spltting the port would make it more manual again.

None of those are killer arguments, but I'm not sure there's a killer
argument for the split either.  It would speed up a rebuild in which
only part of mips.c has changed, but it doesn't take that long to build.

I think we'd only get an "elegant" and consistent split if the target
interface itself was split, rather than being one monolithic structure.

Thanks,
Richard

reload question about unmet constraints

[DJ Delorie]

Given this test case for rl78-elf:

extern __far int a, b;
void ffr (int x)
{
  a = b + x;
}

I'm trying to use this patch:

Index: gcc/config/rl78/rl78-virt.md
===
--- gcc/config/rl78/rl78-virt.md  (revision 227360)
+++ gcc/config/rl78/rl78-virt.md(working copy)
@@ -92,15 +92,15 @@
]
   "rl78_virt_insns_ok ()"
   "v.inc\t%0, %1, %2"
 )
 
 (define_insn "*add3_virt"
-  [(set (match_operand:QHI   0 "rl78_nonfar_nonimm_operand" "=vY,S")
-   (plus:QHI (match_operand:QHI 1 "rl78_nonfar_operand" "viY,0")
- (match_operand:QHI 2 "rl78_general_operand" "vim,i")))
+  [(set (match_operand:QHI   0 "rl78_nonimmediate_operand" "=vY,S,Wfr")
+   (plus:QHI (match_operand:QHI 1 "rl78_general_operand" "viY,0,0")
+ (match_operand:QHI 2 "rl78_general_operand" "vim,i,vi")))
]
   "rl78_virt_insns_ok ()"
   "v.add\t%0, %1, %2"
 )
 
 (define_insn "*sub3_virt"


To allow the rl78 port to generate the "Wfr/0/r" case (alternative 3).
(Wfr = far MEM, v = virtual regs).

I expected gcc to see that the operation doesn't meet the constraints,
and move operands into registers to make it work (alternative 1,
"v/v/v").

Instead, it just complains and dies.

dj.c:42:1: error: insn does not satisfy its constraints:
 }
 ^
(insn 10 15 13 2 (set (mem/c:HI (reg:SI 8 r8) [1 a+0 S2 A16 AS2])
(plus:HI (mem/c:HI (plus:HI (reg/f:HI 32 sp)
(const_int 4 [0x4])) [1 x+0 S2 A16])
(mem/c:HI (symbol_ref:SI ("b") ) [1 b+0 
S2 A16 AS2]))) dj.c:41 13 {*addhi3_virt}
 (nil))
dj.c:42:1: internal compiler error: in extract_constrain_insn, at recog.c:2200


Reloads for insn # 10
Reload 0: reload_in (SI) = (symbol_ref:SI ("a")  )
V_REGS, RELOAD_FOR_INPUT (opnum = 0), inc by 2
reload_in_reg: (symbol_ref:SI ("a")  )
reload_reg_rtx: (reg:SI 8 r8)
Reload 1: reload_in (HI) = (mem/c:HI (plus:HI (reg/f:HI 32 sp)
(const_int 4 [0x4])) [2 
x+0 S2 A16])
reload_out (HI) = (mem/c:HI (plus:HI (reg/f:HI 32 sp)
(const_int 4 [0x4])) [2 
x+0 S2 A16])
V_REGS, RELOAD_OTHER (opnum = 1), optional
reload_in_reg: (mem/c:HI (plus:HI (reg/f:HI 32 sp)
(const_int 4 [0x4])) [2 
x+0 S2 A16])
reload_out_reg: (mem/c:HI (plus:HI (reg/f:HI 32 sp)
(const_int 4 [0x4])) [2 
x+0 S2 A16])
Reload 2: reload_in (HI) = (mem/c:HI (symbol_ref:SI ("b")  ) [2 b+0 S2 A16 AS2])
V_REGS, RELOAD_FOR_INPUT (opnum = 2), optional
reload_in_reg: (mem/c:HI (symbol_ref:SI ("b")  ) [2 b+0 S2 A16 AS2])


So this is where I've been banging my head against the
sources... where is the magic that tells gcc to try to copy everything
into registers to meet the constraints?

Note: expand is ok, the initial add insn is:

(insn 9 3 10 2 (set (reg:HI 48 [ D.1375 ])
(plus:HI (reg/v:HI 45 [ x ])
(mem/c:HI (symbol_ref:SI ("b")  ) [2 b+0 
S2 A16 AS2]))) dj.c:43 -1
 (nil))

and just before reload:

(insn 10 9 0 2 (set (mem/c:HI (symbol_ref:SI ("a")  ) [2 a+0 S2 A16 AS2])
(plus:HI (mem/c:HI (reg/f:HI 33 ap) [2 x+0 S2 A16])
(mem/c:HI (symbol_ref:SI ("b")  ) [2 b+0 
S2 A16 AS2]))) dj.c:43 13 {*addhi3_virt}
 (nil))

Re: Repository for the conversion machinery

[Eric S. Raymond]

Rainer Orth :
> The current entry
> 
> ro = Rainer Orth 
> 
> lists my old email address.  Please use r...@cebitec.uni-bielefeld.de
> instead.

Done.
-- 
http://www.catb.org/~esr/";>Eric S. Raymond

Re: GTY / gengtype question - adding a new header file

[Georg-Johann Lay]

Steve Ellcey schrieb:

I have a question about gengtype and GTY.  I was looking at adding some
code to mips.c and it occurred to me that that file was getting very
large (19873 lines).  So I wanted to add a new .c file instead but that
file needed some types that were defined in mips.c and not in a header file.
Specifically it needed the MIPS specific machine_function structure that
is defined in mips.c with:

struct GTY(())  machine_function {

I think I could just move this to mips.h and things would be fine but
I didn't want to do that because mips.h is included in tm.h and is visible
to the generic GCC code.  Currently machine_function is not visible to the
generic GCC code and so I wanted to put machine_function in a header file
that could only be seen/used by mips specific code.  So I created
mips-private.h and added it to extra_headers in config.gcc.

The problem is that if I include mips-private.h in mips.c instead of
having the actual definition of machine_function in mips.c then my
build fails and I think it is due to how and where gengtype scans for GTY
uses.


Shouldn't it be enough to add the file to config.gcc:target_gtfiles ? 
...and of course including the respective gt-*.h at the bottom of the 
cxx source.



I couldn't find an example of a platform that has a machine specific header
file that was not visible to the generic GCC code and that has GTY types
in it so I am not sure what I need to do to get gengtype to scan
mips-private.h or if this is even possible (or wise).


I'd have a look at what BEs are using non-default target_gtfiles.

Johann

30_threads/timed_mutex/try_lock_until/57641.cc

[Sebastian Huber]

Hello,

in this test case there are two bool test variables (global and local). 
Is this intentional?


--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

Re: Action stamps

[Eric S. Raymond]

Jason Merrill :
> Given git aliases:
> 
> >stamp = show -s --format='%cI!%ce'
> >scommit = "!f(){ d=${1%%!*}; a=${1##*!}; arg=\"--until=$d -1\"; if [ 
> > $a != $1 ]; then arg=\"$arg --committer=$a\"; fi; shift; git rev-list $arg 
> > ${1:+\"$@\"}; }; f"
> >smaster = "!f(){ git scommit \"$1\" trunk --first-parent; }; f"
> >shs = "!f(){ git show $(git smaster $1); }; f"
> >slog = "!f(){ s=$1; shift; git log $(git smaster $s) $*; }; f"
> >sco = "!f(){ git checkout $(git smaster $1); }; f"
> 
> and an action stamp 2015-08-20T20:55:15Z!jason, then
> 
> git sco 2015-08-20T20:55:15Z\!jason
> 
> will check out the (most recent) commit with that stamp.  It also works with
> just the timestamp.

This is a corner of git of which I knew not.  How does one set this sort of
alias?  I Google...

Will git config --global alias.stamp = show -s --format='%cI!%ce

and analogous command lines work?

I think I understand what most of these are doing, but...you would be doing
a service to the world if you wrote a little shellscript that set these up,
with short explanatory comments reveraling what each is to be used for, like
this:

# sco - check out most recent commit with specified action stamp

I'd add that to the reposurgeon distribution in a heartbeat.
-- 
http://www.catb.org/~esr/";>Eric S. Raymond

Acceptance criteria for the git conversion

[Eric S. Raymond]

With the machinery for the git conversion now in reasonable shape, it's
time to ask GCC's developers in general:  what do you want this
conversion to accomplish?

There are some obvious things we might expect it to accomplish, like

(1) Encouraging people to do finer-grained commits because the operation is
so much faster.

(2) Attract developers who think Subversion is clunky and old-fashioned.

(3) Enable bisection as a bug-localization technique.

But there's not much Jason or I can do to advance *those* goals; any
conversion except one that's too crappy to be usable would accomplish them.

What I'm interested in, as I assist the process, is how your desires
ought to affect what we do during the conversion.

As a trivial example of the possibilities, sometimes when I do conversions
I fix obvious comment typos. I generally have to edit the comment history anyway
to tweak comments that don't have git-style summary lines into shape, so
fixing typos is not much additional work.

What kind of mechanical transformation or hand-editing would add value for you?
-- 
http://www.catb.org/~esr/";>Eric S. Raymond

Re: getrlimit compatibility issues

[Jan Hubicka]

> > Yep, this looks like a resonable direction. It will break the one 
> > declaration
> > rule in a more wild sense than current frontends does so, because if a 
> > builtin
> > win as a prevailing declaration, we end up with no merging at all.
> > I wonder if we don't want to always prevail to first non-builtin variant?
> 
> I think we already try.  But this can be tricky as seen by the following
> which is needed to finally fix LTO bootstrap on trunk ...
> 
> Basically there are some function decls that do not go through
> lto-symtab handling because they are not in any CUs cgraph but
> only exist because they are refered to from BLOCK abstract origins
> (and thus also LTRANS boundary streaming doesn't force them
> into the cgraph).  For example during LTO bootstrap I see
> this from inlining of split functions where both split parts and
> the original function are optimized away before stream-out.

Yep, I remember poking around this when I finally stopped my attempts
to get abstract origins working with LTO :(
> 
> We hit
> 
> static void
> gen_inlined_subroutine_die (tree stmt, dw_die_ref context_die)
> {
> ...
>   /* Make sure any inlined functions are known to be inlineable.  */
>   gcc_checking_assert (DECL_ABSTRACT_P (decl)
>|| cgraph_function_possibly_inlined_p (decl));
> 
> a lot without the following fixes.  I suppose we _can_ merge
> function decls which just differ in DECL_POSSIBLY_INLINED if
> we make sure to "merge" the flag during tree merging.  But
> that's for a followup, below is for correctness.

How this is going to work with early debug? If we merge one function to
another, won't we move the references inside blocks to references to another
block tree that is possibly incompatible with one we expect?
> 
> We were also missing to compare DECL_ABSTRACT_ORIGIN during
> tree merging (not sure if that caused any issue, I just run
> into the clone abstract origin issue above and saw that).
> 
> LTO bootstrapped and tested on x86_64-unknown-linux-gnu, I'll throw
> it on regular bootstrap & test and then plan to commit it unless
> you object that lto-symtab.c hunk...
> 
> Richard.
> 
> 2015-08-31  Richard Biener  
> 
>   lto/
>   * lto.c (compare_tree_sccs_1): Compare DECL_ABSTRACT_ORIGIN.
>   * lto-symtab.c (lto_symtab_merge): Merge DECL_POSSIBLY_INLINED flag.
>   (lto_symtab_prevailing_decl): Do not replace a decl that didn't
>   participate in merging with something else.
> 
> Index: gcc/lto/lto.c
> ===
> --- gcc/lto/lto.c (revision 227339)
> +++ gcc/lto/lto.c (working copy)
> @@ -1305,6 +1305,7 @@ compare_tree_sccs_1 (tree t1, tree t2, t
>compare_tree_edges (DECL_SIZE (t1), DECL_SIZE (t2));
>compare_tree_edges (DECL_SIZE_UNIT (t1), DECL_SIZE_UNIT (t2));
>compare_tree_edges (DECL_ATTRIBUTES (t1), DECL_ATTRIBUTES (t2));
> +  compare_tree_edges (DECL_ABSTRACT_ORIGIN (t1), DECL_ABSTRACT_ORIGIN 
> (t2));
>if ((code == VAR_DECL
>  || code == PARM_DECL)
> && DECL_HAS_VALUE_EXPR_P (t1))
> Index: gcc/lto/lto-symtab.c
> ===
> --- gcc/lto/lto-symtab.c  (revision 227339)
> +++ gcc/lto/lto-symtab.c  (working copy)
> @@ -312,6 +312,11 @@ lto_symtab_merge (symtab_node *prevailin
>  
>if (TREE_CODE (decl) == FUNCTION_DECL)
>  {
> +  /* Merge decl state in both directions, we may still end up using
> +  the new decl.  */
> +  DECL_POSSIBLY_INLINED (prevailing_decl) |= DECL_POSSIBLY_INLINED 
> (decl);
> +  DECL_POSSIBLY_INLINED (decl) |= DECL_POSSIBLY_INLINED 
> (prevailing_decl);
> +
>if (warn_type_compatibility_p (TREE_TYPE (prevailing_decl),
>TREE_TYPE (decl)))
>   return false;
> @@ -798,6 +803,18 @@ lto_symtab_prevailing_decl (tree decl)
>if (TREE_CODE (decl) == FUNCTION_DECL && DECL_ABSTRACT_P (decl))
>  return decl;
>  
> +  /* When decl did not participate in symbol resolution leave it alone.
> + This can happen when we streamed the decl as abstract origin
> + from the block tree of inlining a partially inlined function.
> + If all, the split function and the original function end up
> + optimized away early we do not put the abstract origin into the
> + ltrans boundary and we'll end up ICEing in
> + dwarf2out.c:gen_inlined_subroutine_die because we eventually
> + replace a decl with DECL_POSSIBLY_INLINED set with one without.  */
> +  if (TREE_CODE (decl) == FUNCTION_DECL
> +  && ! cgraph_node::get (decl))
> +return decl;

So here you care about not merging DECLs that are not part of symtab with
decls that are part of symtab? I have bit hard time to understand why that
helps.

The rest of patch makes sense to me modulo the possible issues with moving
ECL_ABSTRACT_ORIGIN reference to an incompatible blob of dwarf info comming
from other instance of

[libstdc++] dg-require-atomic-builtins on ARM

[Sebastian Huber]

Hello,

I would like to run as many tests as possible on the arm-rtems target. 
Unfortunately about 100 tests use this:


// { dg-require-atomic-builtins "" }

Which uses a function check_v3_target_atomic_builtins in libstdc++.exp, 
which uses this program to determine if the atomic builtins are available:


puts $f "#if __GCC_ATOMIC_BOOL_LOCK_FREE < 2"
puts $f "#  error No atomic bool"
puts $f "#endif"
puts $f "#if __GCC_ATOMIC_INT_LOCK_FREE < 2"
puts $f "#  error No atomic int"
puts $f "#endif"

The default architecture version on arm-rtems is v4, so 
__GCC_ATOMIC_BOOL_LOCK_FREE == 1 and __GCC_ATOMIC_INT_LOCK_FREE == 1.


How do the other ARM testers tackle this issue? Would it be possible to 
add for example a "-march=armv7-a" option if the target selector 
contains "arm"?


--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

Re: getrlimit compatibility issues

[Richard Biener]

On Tue, 1 Sep 2015, Jan Hubicka wrote:

> > > Yep, this looks like a resonable direction. It will break the one 
> > > declaration
> > > rule in a more wild sense than current frontends does so, because if a 
> > > builtin
> > > win as a prevailing declaration, we end up with no merging at all.
> > > I wonder if we don't want to always prevail to first non-builtin variant?
> > 
> > I think we already try.  But this can be tricky as seen by the following
> > which is needed to finally fix LTO bootstrap on trunk ...
> > 
> > Basically there are some function decls that do not go through
> > lto-symtab handling because they are not in any CUs cgraph but
> > only exist because they are refered to from BLOCK abstract origins
> > (and thus also LTRANS boundary streaming doesn't force them
> > into the cgraph).  For example during LTO bootstrap I see
> > this from inlining of split functions where both split parts and
> > the original function are optimized away before stream-out.
> 
> Yep, I remember poking around this when I finally stopped my attempts
> to get abstract origins working with LTO :(
> > 
> > We hit
> > 
> > static void
> > gen_inlined_subroutine_die (tree stmt, dw_die_ref context_die)
> > {
> > ...
> >   /* Make sure any inlined functions are known to be inlineable.  */
> >   gcc_checking_assert (DECL_ABSTRACT_P (decl)
> >|| cgraph_function_possibly_inlined_p (decl));
> > 
> > a lot without the following fixes.  I suppose we _can_ merge
> > function decls which just differ in DECL_POSSIBLY_INLINED if
> > we make sure to "merge" the flag during tree merging.  But
> > that's for a followup, below is for correctness.
> 
> How this is going to work with early debug? If we merge one function to
> another, won't we move the references inside blocks to references to another
> block tree that is possibly incompatible with one we expect?

Hmm, indeed, if we merge the abstract instance FUNCTION_DECL we end
up adjusting the abstract origin DIE reference accordingly but as
we don't merge BLOCKs the actual BLOCK abstract origins would refer
to the "original" early debug abstract instance.  Not sure if that
will cause problems for the debug consumer - the abstract instances
should be the same (literally, unless you play tricks with #ifdefs
in different uses...).

Note that the current patch-set still clears BLOCK_ABSTRACT_ORIGINS
apart from directly referencing FUNCTION_DECL origins for the
inline outer scope.  One step at a time - streaming all block
abstract origins might work now though, didn't check yet.

> > 
> > We were also missing to compare DECL_ABSTRACT_ORIGIN during
> > tree merging (not sure if that caused any issue, I just run
> > into the clone abstract origin issue above and saw that).
> > 
> > LTO bootstrapped and tested on x86_64-unknown-linux-gnu, I'll throw
> > it on regular bootstrap & test and then plan to commit it unless
> > you object that lto-symtab.c hunk...
> > 
> > Richard.
> > 
> > 2015-08-31  Richard Biener  
> > 
> > lto/
> > * lto.c (compare_tree_sccs_1): Compare DECL_ABSTRACT_ORIGIN.
> > * lto-symtab.c (lto_symtab_merge): Merge DECL_POSSIBLY_INLINED flag.
> > (lto_symtab_prevailing_decl): Do not replace a decl that didn't
> > participate in merging with something else.
> > 
> > Index: gcc/lto/lto.c
> > ===
> > --- gcc/lto/lto.c   (revision 227339)
> > +++ gcc/lto/lto.c   (working copy)
> > @@ -1305,6 +1305,7 @@ compare_tree_sccs_1 (tree t1, tree t2, t
> >compare_tree_edges (DECL_SIZE (t1), DECL_SIZE (t2));
> >compare_tree_edges (DECL_SIZE_UNIT (t1), DECL_SIZE_UNIT (t2));
> >compare_tree_edges (DECL_ATTRIBUTES (t1), DECL_ATTRIBUTES (t2));
> > +  compare_tree_edges (DECL_ABSTRACT_ORIGIN (t1), DECL_ABSTRACT_ORIGIN 
> > (t2));
> >if ((code == VAR_DECL
> >|| code == PARM_DECL)
> >   && DECL_HAS_VALUE_EXPR_P (t1))
> > Index: gcc/lto/lto-symtab.c
> > ===
> > --- gcc/lto/lto-symtab.c(revision 227339)
> > +++ gcc/lto/lto-symtab.c(working copy)
> > @@ -312,6 +312,11 @@ lto_symtab_merge (symtab_node *prevailin
> >  
> >if (TREE_CODE (decl) == FUNCTION_DECL)
> >  {
> > +  /* Merge decl state in both directions, we may still end up using
> > +the new decl.  */
> > +  DECL_POSSIBLY_INLINED (prevailing_decl) |= DECL_POSSIBLY_INLINED 
> > (decl);
> > +  DECL_POSSIBLY_INLINED (decl) |= DECL_POSSIBLY_INLINED 
> > (prevailing_decl);
> > +
> >if (warn_type_compatibility_p (TREE_TYPE (prevailing_decl),
> >  TREE_TYPE (decl)))
> > return false;
> > @@ -798,6 +803,18 @@ lto_symtab_prevailing_decl (tree decl)
> >if (TREE_CODE (decl) == FUNCTION_DECL && DECL_ABSTRACT_P (decl))
> >  return decl;
> >  
> > +  /* When decl did not participate in symbol resolution leave it alone.
> > + This can happen wh

Re: [libstdc++] dg-require-atomic-builtins on ARM

[Andreas Schwab]

Sebastian Huber  writes:

> How do the other ARM testers tackle this issue? Would it be possible to
> add for example a "-march=armv7-a" option if the target selector contains
> "arm"?

RUNTESTFLAGS=--target_board=unix\{,-march=armv7-a\}

Andreas.

-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: Acceptance criteria for the git conversion

[Joseph Myers]

On Tue, 1 Sep 2015, Eric S. Raymond wrote:

> As a trivial example of the possibilities, sometimes when I do conversions
> I fix obvious comment typos. I generally have to edit the comment history 
> anyway
> to tweak comments that don't have git-style summary lines into shape, so
> fixing typos is not much additional work.

With 227369 revisions I don't think adding git-style summary lines is 
really practical without some very reliable automation to match commits to 
corresponding gcc-patches messages (whose Subject: headers would be the 
natural choice for such summary lines)

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Acceptance criteria for the git conversion

[Rainer Orth]

Joseph Myers  writes:

> On Tue, 1 Sep 2015, Eric S. Raymond wrote:
>
>> As a trivial example of the possibilities, sometimes when I do conversions
>> I fix obvious comment typos. I generally have to edit the comment history
>> anyway
>> to tweak comments that don't have git-style summary lines into shape, so
>> fixing typos is not much additional work.
>
> With 227369 revisions I don't think adding git-style summary lines is 
> really practical without some very reliable automation to match commits to 
> corresponding gcc-patches messages (whose Subject: headers would be the 
> natural choice for such summary lines)

And even that wouldn't work, I believe: a considerable number of patches
are submitted in the context of some thread whose patch e.g. introduced
a regression or bootstrap failure, without changing the subject.  So,
unless you detect this case and make something up, the result is likely
to be confusing rather than helpful.

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: getrlimit compatibility issues

[Jan Hubicka]

> On Tue, 1 Sep 2015, Jan Hubicka wrote:
> 
> > > > Yep, this looks like a resonable direction. It will break the one 
> > > > declaration
> > > > rule in a more wild sense than current frontends does so, because if a 
> > > > builtin
> > > > win as a prevailing declaration, we end up with no merging at all.
> > > > I wonder if we don't want to always prevail to first non-builtin 
> > > > variant?
> > > 
> > > I think we already try.  But this can be tricky as seen by the following
> > > which is needed to finally fix LTO bootstrap on trunk ...
> > > 
> > > Basically there are some function decls that do not go through
> > > lto-symtab handling because they are not in any CUs cgraph but
> > > only exist because they are refered to from BLOCK abstract origins
> > > (and thus also LTRANS boundary streaming doesn't force them
> > > into the cgraph).  For example during LTO bootstrap I see
> > > this from inlining of split functions where both split parts and
> > > the original function are optimized away before stream-out.
> > 
> > Yep, I remember poking around this when I finally stopped my attempts
> > to get abstract origins working with LTO :(
> > > 
> > > We hit
> > > 
> > > static void
> > > gen_inlined_subroutine_die (tree stmt, dw_die_ref context_die)
> > > {
> > > ...
> > >   /* Make sure any inlined functions are known to be inlineable.  */
> > >   gcc_checking_assert (DECL_ABSTRACT_P (decl)
> > >|| cgraph_function_possibly_inlined_p (decl));
> > > 
> > > a lot without the following fixes.  I suppose we _can_ merge
> > > function decls which just differ in DECL_POSSIBLY_INLINED if
> > > we make sure to "merge" the flag during tree merging.  But
> > > that's for a followup, below is for correctness.
> > 
> > How this is going to work with early debug? If we merge one function to
> > another, won't we move the references inside blocks to references to another
> > block tree that is possibly incompatible with one we expect?
> 
> Hmm, indeed, if we merge the abstract instance FUNCTION_DECL we end
> up adjusting the abstract origin DIE reference accordingly but as
> we don't merge BLOCKs the actual BLOCK abstract origins would refer
> to the "original" early debug abstract instance.  Not sure if that
> will cause problems for the debug consumer - the abstract instances
> should be the same (literally, unless you play tricks with #ifdefs
> in different uses...).
> 
> > The rest of patch makes sense to me modulo the possible issues with moving
> > ECL_ABSTRACT_ORIGIN reference to an incompatible blob of dwarf info comming
> > from other instance of the inlined function from other translation unit.
> > 
> > I see you added DECL_ABSTRACT_ORIGIN comparer, but that won't make block 
> > numbers
> > to match. 
> 
> Who cares about block numbers?  Note the abstract origin comparer was
> for the clone abstract origins we have.

Yep, no one in dwarf2out.  My original attempt used it to refer to BLOCKs within
a different function body (BLOCK_ABSTRACT_ORIGIN). We currently don't stream 
it, so
we don't need to refer to it.

In longer run we will however need a way to make these references to work...
Merging them will be tricky as it would require comparing the function's block 
trees.
Especially after early inlining these tends to diverge, but perhaps the early 
debug is output
before early inlining and thus this problem goes away and we only care about 
different ifdefs.
Those are quite common, too, however, at least in Firefox :(

Honza
> 
> Richard.

Re: Acceptance criteria for the git conversion

[David Malcolm]

On Tue, 2015-09-01 at 06:54 -0400, Eric S. Raymond wrote:
> With the machinery for the git conversion now in reasonable shape, it's
> time to ask GCC's developers in general:  what do you want this
> conversion to accomplish?
> 
> There are some obvious things we might expect it to accomplish, like
> 
> (1) Encouraging people to do finer-grained commits because the operation is
> so much faster.

FWIW, I'm not convinced (1) is so relevant to gcc.  For me, most of my
time spent on committing patches to gcc is the part where I'm waiting on
my machine to do bootstrap®ression testing; the actual commit is
relatively fast.   I believe we have a policy that although we may break
up patches into chunks for ease of review, commits themselves should be
"atomic", so that the repository is always in a working state.  At
least, that's the ideal :)

> (2) Attract developers who think Subversion is clunky and old-fashioned.

Yes, though I think many of us do almost all of our gcc work using git
already, using the git-svn mirror, and only touch svn for the final
commit.

Hence I think this is more a marketing "smell" thing: potential
developers may see "SVN" on our website and go "ugh!  gcc is so old
fashioned!", but the reality for me is that I can already do almost all
of my gcc work in git without touching svn.

> (3) Enable bisection as a bug-localization technique.

> But there's not much Jason or I can do to advance *those* goals; any
> conversion except one that's too crappy to be usable would accomplish them.
> 
> What I'm interested in, as I assist the process, is how your desires
> ought to affect what we do during the conversion.
> 
> As a trivial example of the possibilities, sometimes when I do conversions
> I fix obvious comment typos. I generally have to edit the comment history 
> anyway
> to tweak comments that don't have git-style summary lines into shape, so
> fixing typos is not much additional work.
> 
> What kind of mechanical transformation or hand-editing would add value for 
> you?

Will the resulting git commits have some kind of metadata identifying
the corresponding SVN revision?   For example, I see something like this
in the git svn mirror e.g. this line shows up for
0c0caab66d411b8df6a9057d788f1c8bcf77a83a:

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@226697 
138bc75d-0d04-0410-961f-82ee72b054a4

We have numerous references to specific revisions in bugzilla and in the
list archives, so retaining this mapping seems very useful for future
"archaeological digs"; it would be a major regression compared to the
git-svn mirror if we lost them.

Similarly, our bugzilla automatically turns text like "r226697" into
links to the relevant commit in SVN.  I don't know if there's a way to
maintain those links for git (beyond e.g. creating a named tag for every
r[0-9]+, but that's clearly insane), so presumably we'd want to keep the
old SVN web interface around to service those bugzilla URLs?


I'd love it if the commits gained readable titles (where they don't
already).  For example, if I run "git shortlog" (on a working copy from
the git-svn mirror), I see this for some of my commits:
  2013-08-06  David Malcolm  
  2013-08-07  David Malcolm  
  2013-08-07  David Malcolm  
  2013-08-07  David Malcolm  
  2013-08-07  David Malcolm  
  2013-08-13  David Malcolm  
  gcc/testsuite
  gcc/testsuite
(etc)
which is less than helpful.  Since I noticed this, I've been trying to
add decent title lines to my SVN commits so that they show up nicely in
git.

So it'd be great if a script could identify those commit titles that are
just the top of ChangeLog entries, scrape the gcc-patches mailing list
archives for try to locate the Subject lines of the pertinent patches
(and clean away extraneous [PATCH] or [PING] fragments, though other
fragments may be pertinent e.g. identifying subsystems).  Potentially it
could also add the URL of the discussion in the list archive.  Clearly a
non-trivial task though.

Thanks; hope this is constructive
Dave

Re: getrlimit compatibility issues

[Richard Biener]

On Tue, 1 Sep 2015, Jan Hubicka wrote:

> > On Tue, 1 Sep 2015, Jan Hubicka wrote:
> > 
> > > > > Yep, this looks like a resonable direction. It will break the one 
> > > > > declaration
> > > > > rule in a more wild sense than current frontends does so, because if 
> > > > > a builtin
> > > > > win as a prevailing declaration, we end up with no merging at all.
> > > > > I wonder if we don't want to always prevail to first non-builtin 
> > > > > variant?
> > > > 
> > > > I think we already try.  But this can be tricky as seen by the following
> > > > which is needed to finally fix LTO bootstrap on trunk ...
> > > > 
> > > > Basically there are some function decls that do not go through
> > > > lto-symtab handling because they are not in any CUs cgraph but
> > > > only exist because they are refered to from BLOCK abstract origins
> > > > (and thus also LTRANS boundary streaming doesn't force them
> > > > into the cgraph).  For example during LTO bootstrap I see
> > > > this from inlining of split functions where both split parts and
> > > > the original function are optimized away before stream-out.
> > > 
> > > Yep, I remember poking around this when I finally stopped my attempts
> > > to get abstract origins working with LTO :(
> > > > 
> > > > We hit
> > > > 
> > > > static void
> > > > gen_inlined_subroutine_die (tree stmt, dw_die_ref context_die)
> > > > {
> > > > ...
> > > >   /* Make sure any inlined functions are known to be inlineable.  */
> > > >   gcc_checking_assert (DECL_ABSTRACT_P (decl)
> > > >|| cgraph_function_possibly_inlined_p (decl));
> > > > 
> > > > a lot without the following fixes.  I suppose we _can_ merge
> > > > function decls which just differ in DECL_POSSIBLY_INLINED if
> > > > we make sure to "merge" the flag during tree merging.  But
> > > > that's for a followup, below is for correctness.
> > > 
> > > How this is going to work with early debug? If we merge one function to
> > > another, won't we move the references inside blocks to references to 
> > > another
> > > block tree that is possibly incompatible with one we expect?
> > 
> > Hmm, indeed, if we merge the abstract instance FUNCTION_DECL we end
> > up adjusting the abstract origin DIE reference accordingly but as
> > we don't merge BLOCKs the actual BLOCK abstract origins would refer
> > to the "original" early debug abstract instance.  Not sure if that
> > will cause problems for the debug consumer - the abstract instances
> > should be the same (literally, unless you play tricks with #ifdefs
> > in different uses...).
> > 
> > > The rest of patch makes sense to me modulo the possible issues with moving
> > > ECL_ABSTRACT_ORIGIN reference to an incompatible blob of dwarf info 
> > > comming
> > > from other instance of the inlined function from other translation unit.
> > > 
> > > I see you added DECL_ABSTRACT_ORIGIN comparer, but that won't make block 
> > > numbers
> > > to match. 
> > 
> > Who cares about block numbers?  Note the abstract origin comparer was
> > for the clone abstract origins we have.
> 
> Yep, no one in dwarf2out.  My original attempt used it to refer to BLOCKs 
> within
> a different function body (BLOCK_ABSTRACT_ORIGIN). We currently don't stream 
> it, so
> we don't need to refer to it.
> 
> In longer run we will however need a way to make these references to work...
> Merging them will be tricky as it would require comparing the function's 
> block trees.
> Especially after early inlining these tends to diverge, but perhaps the early 
> debug is output
> before early inlining and thus this problem goes away and we only care about 
> different ifdefs.
> Those are quite common, too, however, at least in Firefox :(

I think it should simply work - dependent on what the debug info
consumer does to the two block trees (we do _not_ add references
to the abstract BLOCKs, only to the abstract variables):

 <2><1e7>: Abbrev Number: 7 (DW_TAG_inlined_subroutine)
<1e8>   DW_AT_abstract_origin: <0x3d2>
<1ec>   DW_AT_low_pc  : 0x4006bc
<1f4>   DW_AT_high_pc : 0xf4
<1fc>   DW_AT_call_file   : 1
<1fd>   DW_AT_call_line   : 44
<1fe>   DW_AT_sibling : <0x234>
 <3><202>: Abbrev Number: 8 (DW_TAG_formal_parameter)
<203>   DW_AT_abstract_origin: <0x3e2>
<207>   DW_AT_location: 2 byte block: 91 4c (DW_OP_fbreg: -52)
 <3><20a>: Abbrev Number: 9 (DW_TAG_lexical_block)
<20b>   DW_AT_low_pc  : 0x4006bc
<213>   DW_AT_high_pc : 0xf4
 <4><21b>: Abbrev Number: 10 (DW_TAG_variable)
<21c>   DW_AT_abstract_origin: <0x3eb>
<220>   DW_AT_location: 3 byte block: 91 98 7e  (DW_OP_fbreg: 
-232)
...

so if the <0x3d2> lexical blocks do not "match" with the <1e7> ones
then what does the consumer do?  I suppose it simply doesn't care
for "blocks" at all apart from source of scope pc-range info.

We always have the choice to fix the consumer after all.

Richard.

Re: [libstdc++] dg-require-atomic-builtins on ARM

[Sebastian Huber]

On 01/09/15 14:22, Andreas Schwab wrote:

Sebastian Huber  writes:


How do the other ARM testers tackle this issue? Would it be possible to
add for example a "-march=armv7-a" option if the target selector contains
"arm"?

RUNTESTFLAGS=--target_board=unix\{,-march=armv7-a\}


Thanks for this hint. Do you know the magic to use more than one machine 
option, e.g. -march=armv7-a -mthumb? I tried several ways to quote the 
space character, and so on, but nothing worked. I didn't find any 
documentation for this {} stuff.


--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

Re: [libstdc++] dg-require-atomic-builtins on ARM

[Andreas Schwab]

Sebastian Huber  writes:

> Thanks for this hint. Do you know the magic to use more than one machine
> option, e.g. -march=armv7-a -mthumb?

RUNTESTFLAGS=--target_board=unix\{,-march=armv7-a/-mthumb\}

Andreas.

-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: Acceptance criteria for the git conversion

[Mikhail Maltsev]

On 09/01/2015 01:54 PM, Eric S. Raymond wrote:
> With the machinery for the git conversion now in reasonable shape, it's
> time to ask GCC's developers in general:  what do you want this
> conversion to accomplish?
There was some discussion concerning file renaming:
https://gcc.gnu.org/ml/gcc/2015-04/msg00175.html

I think using different extensions for C and C++ code is a good thing (because 
having
C++ code in ".c" files is confusing both for humans and for tools), and probably
moving to git is a good occasion for such rename.
I could take care of performing this change (i.e. make a list of C++ files with 
.c
extension, fix build scripts, run some tests), if it is acceptable.

-- 
Regards,
Mikhail Maltsev

Re: Action stamps

[Jonathan Wakely]

On 1 September 2015 at 10:21, Eric S. Raymond wrote:
> Jason Merrill :
>> Given git aliases:
>>
>> >stamp = show -s --format='%cI!%ce'
>> >scommit = "!f(){ d=${1%%!*}; a=${1##*!}; arg=\"--until=$d -1\"; if 
>> > [ $a != $1 ]; then arg=\"$arg --committer=$a\"; fi; shift; git rev-list 
>> > $arg ${1:+\"$@\"}; }; f"
>> >smaster = "!f(){ git scommit \"$1\" trunk --first-parent; }; f"
>> >shs = "!f(){ git show $(git smaster $1); }; f"
>> >slog = "!f(){ s=$1; shift; git log $(git smaster $s) $*; }; f"
>> >sco = "!f(){ git checkout $(git smaster $1); }; f"
>>
>> and an action stamp 2015-08-20T20:55:15Z!jason, then
>>
>> git sco 2015-08-20T20:55:15Z\!jason
>>
>> will check out the (most recent) commit with that stamp.  It also works with
>> just the timestamp.
>
> This is a corner of git of which I knew not.  How does one set this sort of
> alias?  I Google...
>
> Will git config --global alias.stamp = show -s --format='%cI!%ce
>
> and analogous command lines work?

No. You don't want the = in there to set an alias, and you need to
quote the "show -s ..." string, and escape suitably. It's easier just
to add the lines directly to ~/.gitconfig, which also lets you add a
comment saying what it does.

Re: Acceptance criteria for the git conversion

[Richard Earnshaw]

On 01/09/15 15:26, Mikhail Maltsev wrote:
> On 09/01/2015 01:54 PM, Eric S. Raymond wrote:
>> With the machinery for the git conversion now in reasonable shape, it's
>> time to ask GCC's developers in general:  what do you want this
>> conversion to accomplish?
> There was some discussion concerning file renaming:
> https://gcc.gnu.org/ml/gcc/2015-04/msg00175.html
> 
> I think using different extensions for C and C++ code is a good thing 
> (because having
> C++ code in ".c" files is confusing both for humans and for tools), and 
> probably
> moving to git is a good occasion for such rename.
> I could take care of performing this change (i.e. make a list of C++ files 
> with .c
> extension, fix build scripts, run some tests), if it is acceptable.
> 

Renaming the files during the conversion is clearly *not* the right
thing to do: it would break all builds of old code.

Whether the renames should be done post conversion is a completely
different question.  Personally, I don't see the point.

R.

Re: Repository for the conversion machinery

[Julian Brown]

On Fri, 28 Aug 2015 17:50:53 +
Joseph Myers  wrote:

> shinwell = Mark Shinwell 
>   (Jane Street)

Mark's current address is mshinw...@janestreet.com.

Julian

Re: Acceptance criteria for the git conversion

[David Edelsohn]

On Tue, Sep 1, 2015 at 10:26 AM, Mikhail Maltsev  wrote:
> On 09/01/2015 01:54 PM, Eric S. Raymond wrote:
>> With the machinery for the git conversion now in reasonable shape, it's
>> time to ask GCC's developers in general:  what do you want this
>> conversion to accomplish?
> There was some discussion concerning file renaming:
> https://gcc.gnu.org/ml/gcc/2015-04/msg00175.html
>
> I think using different extensions for C and C++ code is a good thing 
> (because having
> C++ code in ".c" files is confusing both for humans and for tools), and 
> probably
> moving to git is a good occasion for such rename.
> I could take care of performing this change (i.e. make a list of C++ files 
> with .c
> extension, fix build scripts, run some tests), if it is acceptable.

Definitely not.

- David

Re: Action stamps

[Jason Merrill]

On 09/01/2015 05:21 AM, Eric S. Raymond wrote:

Jason Merrill :

Given git aliases:


stamp = show -s --format='%cI!%ce'
scommit = "!f(){ d=${1%%!*}; a=${1##*!}; arg=\"--until=$d -1\"; if [ $a != $1 ]; then 
arg=\"$arg --committer=$a\"; fi; shift; git rev-list $arg ${1:+\"$@\"}; }; f"
smaster = "!f(){ git scommit \"$1\" trunk --first-parent; }; f"
shs = "!f(){ git show $(git smaster $1); }; f"
slog = "!f(){ s=$1; shift; git log $(git smaster $s) $*; }; f"
sco = "!f(){ git checkout $(git smaster $1); }; f"


and an action stamp 2015-08-20T20:55:15Z!jason, then

git sco 2015-08-20T20:55:15Z\!jason

will check out the (most recent) commit with that stamp.  It also works with
just the timestamp.


This is a corner of git of which I knew not.  How does one set this sort of
alias?  I Google...

Will git config --global alias.stamp = show -s --format='%cI!%ce

and analogous command lines work?


As Jonathan says, I was editing them directly into the [alias] section 
of my ~/.gitconfig .



I think I understand what most of these are doing, but...you would be doing
a service to the world if you wrote a little shellscript that set these up,
with short explanatory comments reveraling what each is to be used for, like
this:

# sco - check out most recent commit with specified action stamp

I'd add that to the reposurgeon distribution in a heartbeat.


Here's an improved version:


# git stamp  - print a reposurgeon-style action stamp
stamp = show -s --format='%cI!%ce'

# git scommit   - list the most recent commit that 
matches .
# Must also specify a branch to search or --all.
scommit = "!f(){ d=${1%%!*}; a=${1##*!}; arg=\"--until=$d -1\"; if [ $a != $1 ]; then 
arg=\"$arg --committer=$a\"; fi; shift; git rev-list $arg ${1:+\"$@\"}; }; f"

# git scommits   - as above, but list all 
matching commits.
scommits = "!f(){ d=${1%%!*}; a=${1##*!}; arg=\"--until=$d --after $d\"; if [ $a != $1 ]; then 
arg=\"$arg --committer=$a\"; fi; shift; git rev-list $arg ${1:+\"$@\"}; }; f"

# git smaster  - list the most recent commit on master that matches 
.
smaster = "!f(){ git scommit \"$1\" master --first-parent; }; f"
smasters = "!f(){ git scommits \"$1\" master --first-parent; }; f"

# git shs  - show the commits on master that match .
shs = "!f(){ stamp=$(git smasters $1); shift; git show ${stamp:?not found} 
$*; }; f"

# git slog   - start git log at  on master
slog = "!f(){ stamp=$(git smaster $1); shift; git log ${stamp:?not found} 
$*; }; f"

# git sco  - check out the most recent commit on master that matches 
.
sco = "!f(){ stamp=$(git smaster $1); shift; git checkout ${stamp:?not 
found} $*; }; f"


Jason

Re: Acceptance criteria for the git conversion

[Eric S. Raymond]

Joseph Myers :
> With 227369 revisions I don't think adding git-style summary lines is 
> really practical without some very reliable automation to match commits to 
> corresponding gcc-patches messages (whose Subject: headers would be the 
> natural choice for such summary lines)

In this case you may be right.  Select =L tells me there are 101139
commits wanting that sort of adjustment, which I think is at least
2.5x the bulk I've ever had to deal with before.

Still, if anyone else is brave enough to write a script that will munch
through gcc-patches producing committer/date/subject-line triples, I'll
give it a try.

About scale:  The largest repository I've dealt with before this was
NetBSD, with a working set of 18GB, vs 45GB for this one.  The way reposurgeon's
internal representations work, working set is dominated by comment text.  So
the GCC repo has about 2.5x the comment bulk of NetBSD.
-- 
http://www.catb.org/~esr/";>Eric S. Raymond

Re: Acceptance criteria for the git conversion

[Eric S. Raymond]

David Malcolm :
> > What kind of mechanical transformation or hand-editing would add value for
> >you?
> 
> Will the resulting git commits have some kind of metadata identifying
> the corresponding SVN revision?

That's what the --legacy option does.  I think Jason plans to use it.

I've noted previously that I actually recommend against this based on
previous experience with Subversion conversions.  You get a lot of
clutter in the result and demand for such lookups (especially *outside
the specific context of a buglist*) tends to drop off faster than
people expect.  But that policy decision isn't mine to make.

> Similarly, our bugzilla automatically turns text like "r226697" into
> links to the relevant commit in SVN.  I don't know if there's a way to
> maintain those links for git (beyond e.g. creating a named tag for every
> r[0-9]+, but that's clearly insane), so presumably we'd want to keep the
> old SVN web interface around to service those bugzilla URLs?

There is no way to maintain those links for git, so yes, you want to
keep a read-only Subversion instance around.

This also lowers the utility of keeping the legacy-ID in every commit.

> So it'd be great if a script could identify those commit titles that are
> just the top of ChangeLog entries, scrape the gcc-patches mailing list
> archives for try to locate the Subject lines of the pertinent patches
> (and clean away extraneous [PATCH] or [PING] fragments, though other
> fragments may be pertinent e.g. identifying subsystems).  Potentially it
> could also add the URL of the discussion in the list archive.  Clearly a
> non-trivial task though.

There was already some discussion of this.  If someone else is willing
to digest the gcc-patches archives into committer/date/subject-line
triples I'll see what I can do.

> Thanks; hope this is constructive

Yes, very much the sort of thing I was looking for.
-- 
http://www.catb.org/~esr/";>Eric S. Raymond

Re: Action stamps

[Eric S. Raymond]

Jason Merrill :
> Here's an improved version:

You wrote:

# git scommit   - list most recent commit that matches 
.
# Must also specify a branch to search or --all.

Where must the branch argument appear with respect to the other arguments?

Am I correct that this should be applied by creating or appending to an
[alias] section in ~/.gitconfig?
-- 
http://www.catb.org/~esr/";>Eric S. Raymond

Re: Acceptance criteria for the git conversion

[Andreas Schwab]

"Eric S. Raymond"  writes:

> There is no way to maintain those links for git, so yes, you want to
> keep a read-only Subversion instance around.

The mapping can also be put in some git notes tree for use by bugzilla.
That would only need to be set up once.

Andreas.

-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: GTY / gengtype question - adding a new header file

[Steve Ellcey]

On Tue, 2015-09-01 at 08:11 +0100, Richard Sandiford wrote:

> config.gcc would need to add mips-private.h to target_gtfiles.

OK, that was what I missed.

> I'm not sure splitting the file is a good idea though.  At the moment
> the definitions of all target hooks must be visible to a single TU.
> Either you'd need to keep all the hooks in one .c file (leading
> to an artificial split IMO) or you'd need declare some of them
> in the private header.  Declaring them in the header file would only be
> consistent if the targetm definition was in its own file (so that _every_
> hook had a prototype in the private header).  That seems like unnecessary
> work though.

The code I want to add is actually a separate GCC pass so it breaks out
fairly cleanly.  It just needs access to the machine_function structure
and the types and structures included in that structure
(mips_frame_info, mips_int_mask, and mips_shadow_set).  It sets a couple
of new boolean variables in the machine_function structure which are
then used during mips_compute_frame_info.

I see what you mean about much of mips.c probably not being splittable
due to the target hook structure but machine specific passes may be the
exception to that rule.  We already have one pass in mips.c
(pass_mips_machine_reorg2), that might be something else that could be
broken out, though I haven't looked in detail to see what types or
structures it would need access to.

Steve Ellcey
sell...@imgtec.com

Re: Action stamps

[Jason Merrill]

On 09/01/2015 11:59 AM, Eric S. Raymond wrote:

Jason Merrill :

Here's an improved version:


You wrote:

# git scommit   - list most recent commit that matches 
.
# Must also specify a branch to search or --all.

Where must the branch argument appear with respect to the other arguments?


After the stamp; otherwise it doesn't matter, it'll just be passed along 
to git rev-list.



Am I correct that this should be applied by creating or appending to an
[alias] section in ~/.gitconfig?


Yes.

Jason

Re: GTY / gengtype question - adding a new header file

[Steve Ellcey]

On Tue, 2015-09-01 at 10:13 +0200, Georg-Johann Lay wrote:

> 
> I'd have a look at what BEs are using non-default target_gtfiles.
> 
> Johann

There are a few BEs that add a .c file to target_gtfiles, but no
platforms that add a .h file to target_gtfiles.  I do see a number
of platforms that define the machine_function structure in their header
file (aarch64.h, pa.h, i386.h) instead of their .c file though.

Maybe that is a better way to go for MIPS instead of doing something
completely new.  If I move machine_function, mips_frame_info,
mips_int_mask, and mips_shadow_set from mips.c to mips.h then I could
put my new machine specific pass in a separate .c file from mips.c and
not need to do anything with target_gtfiles.  The only reason I didn't
want to do this was so that machine_function wasn't visible to the rest
of GCC but that doesn't seem to have been an issue for other targets.

Steve Ellcey
sell...@imgtec.com

Re: Acceptance criteria for the git conversion

[Joseph Myers]

On Tue, 1 Sep 2015, Richard Earnshaw wrote:

> Renaming the files during the conversion is clearly *not* the right
> thing to do: it would break all builds of old code.

Indeed.  Ideally the tree objects in the git conversion should have 
exactly the same contents as SVN commits, and so be shared with the 
git-svn history to reduce the eventual repository size (except where there 
are defects in the git-svn history, or the git conversion fixes up cvs2svn 
artifacts and so some old revisions end up more accurately reflecting old 
history than the SVN repository does).

One particular case: we have well-maintained .gitignore files, that might 
even be more accurate than the svn:ignore properties, and I think the 
conversion should keep those and disable all smart ignore handling (just 
discard svn:ignore properties, and pass through the existing .gitignore 
files (and .cvsignore files)).

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Acceptance criteria for the git conversion

[Eric S. Raymond]

Joseph Myers :
> Indeed.  Ideally the tree objects in the git conversion should have 
> exactly the same contents as SVN commits, and so be shared with the 
> git-svn history to reduce the eventual repository size (except where there 
> are defects in the git-svn history, or the git conversion fixes up cvs2svn 
> artifacts and so some old revisions end up more accurately reflecting old 
> history than the SVN repository does).

I don't think sharing with the git-svn history will be possible.  git-svn
is a terrible whole-history converter; the odds of getting the same
topology out of reposurgeon are basically nil, and the problem of matching
different topologies is quite hard.

I'll be frank; if it's doable at all (which I doubt) I think this is a
*really bad idea* - a complexity hairball with few or no actual benefits.
I'm not willing to even try for it unless demand from the development
group is overwhelming and you're able to wait a long, long time for
results.

> One particular case: we have well-maintained .gitignore files, that might 
> even be more accurate than the svn:ignore properties, and I think the 
> conversion should keep those and disable all smart ignore handling (just 
> discard svn:ignore properties, and pass through the existing .gitignore 
> files (and .cvsignore files)).

This is also not currently possible, but it's not an intrinsically bad
idea. Giving reposurgeon an option to to support it wouldn't be very
difficult.
-- 
http://www.catb.org/~esr/";>Eric S. Raymond

Awareness of register pressure on strength reduction of induction variables.

[Ajit Kumar Agarwal]

All;

The Global code motion are the important optimization that have an impact on 
register spills and Fetch. Thus
The Global code motion takes into account the increase or decrease of register 
pressure.

Strength Reductions is an important optimization that has an impact on register 
pressure. The strength reduction
Optimizations doesn't take into account the register pressure and especially 
the strength reduction for induction
Variables that are inside the Loops. Loops are the bottleneck for the register 
pressure and any spill inside the loops
Based on strength reduction of induction variables degrades the performance of 
the Loops.

Thus the strength reductions in general and especially the strength reduction 
for induction variables should take
Into account the register pressure based on Live range info.

I don't think we do take into account the register pressure for strength 
reduction optimization in general and especially the 
Strength reduction based on induction variables.

Thanks & Regards
Ajit

Commoning the control and Data Dependence

[Ajit Kumar Agarwal]

All:

The Data Dependency graph augmented with control dependence can be common out 
based on the dominator info.
The instruction I1 dominates all the uses say instruction I2 and I3. Then I2 
and I3 depends on I1. Thus the Graph can be 
Formed from the dominator tree of all the instructions and the edges represent 
the dominator info. There is an edge 
From I1 - I2 and I1-I3 if I1 dominates I2 and I3.

Such representation can be common out with Data and control dependence and the 
common data structure can be 
Formed with the tree based graph on dominator info. This will take care of both 
the Data Dependence and the control
Dependence with the common representation of the graph on dominator tree info 
based out of instructions.

Such representation can be augmented with DDG augmented with Control dependence 
used in Loop distribution pass
To form the partitions to distribute the Loops?

Thanks & Regards
Ajit

Re: Acceptance criteria for the git conversion

[Joseph Myers]

On Tue, 1 Sep 2015, Eric S. Raymond wrote:

> Joseph Myers :
> > Indeed.  Ideally the tree objects in the git conversion should have 
> > exactly the same contents as SVN commits, and so be shared with the 
> > git-svn history to reduce the eventual repository size (except where there 
> > are defects in the git-svn history, or the git conversion fixes up cvs2svn 
> > artifacts and so some old revisions end up more accurately reflecting old 
> > history than the SVN repository does).
> 
> I don't think sharing with the git-svn history will be possible.  git-svn
> is a terrible whole-history converter; the odds of getting the same
> topology out of reposurgeon are basically nil, and the problem of matching
> different topologies is quite hard.

I'm not proposing sharing topology (commit objects).  Only blob and tree 
objects.  If two files have the same hash they will share the same blob 
object, and if two trees have files with the same hashes at the same paths 
then the tree objects will also have the same hash, and will be shared.  
Now, git-svn may well have made mistakes meaning some trees in the git-svn 
repository do not accurately correspond to any SVN revision of any branch 
(and so the objects aren't shared), but I'd expect most to be shared (even 
without disabling smart ignore handling, lots of tree objects for 
subdirectories would be shared, if those subdirectories don't have any 
ignore files or svn:ignore properties).

The point is that since the git-svn repository has been in use for years, 
and there are many git-only branches there with lots of development on 
them, there are also many git commit references in list archives etc. 
which need to remain meaningful.  While it would be possible to move the 
existing repository to a different URI (or put the new repository at a 
less-obvious URI), it seems simpler to put both sets of objects (with many 
objects in common) in the same repository (with appropriately renamed refs 
from the git-svn repository so that the objects aren't garbage-collected).

This isn't something for reposurgeon to do.  It's something that should be 
easy to do at the pure git level.  At a minimum, I think it might be just 
one command to add the git-svn objects to a repository converted with 
reposurgeon.  Untested, but should give an idea of what I'm thinking of:

git fetch git://gcc.gnu.org/git/gcc.git \
'refs/heads/*:refs/heads/git-old/*' \
'refs/remotes/*:refs/heads/git-svn-old/*' \
'regs/tags/*:refs/tags/git-old/*'

(OK, you want to git gc afterwards to repack the whole repository.)

-- 
Joseph S. Myers
jos...@codesourcery.com

Live range Analysis based on tree representations

[Ajit Kumar Agarwal]

All:

The Live ranges info on tree SSA representation is important step towards the 
SSA based code motion optimizations.
As the code motion optimization based on the SSA representation effects the 
register pressure and reasons for performance
Bottleneck.

I am proposing the Live range Analysis based on the SSA representation. The 
Live range analysis traverses the dominator
Tree. The SSA and phi variables are represented based on dominance frontier 
info and the SSA representation reflects
The dominance info. Based on such dominance info Live range Overlapping 
Analysis can be derived.

Variable V intersects W if Vdef dominates the Wdef. The variable v intersects 
at point p if Vdef dominates P and Wdef
Dominates the P. If Vdef dominates Wdef and Wdef dominates Udef , then the Vdef 
dominates Udef and thus Live range
Of V intersect W and live range W intersect U, thus the live range V intersects 
the U. Such dominance info can be used to
Represent the Overlapping Live range Analysis and the register pressure is 
derived from Overlapping Live ranges based 
On the dominator info inherited from the SSA representation. The SSA 
representation is derived based on dominance
Frontier and the traversal of dominator tree based on SSA can derive the 
Overlapping Live ranges.

The above Overlapping Live range info can be used to derive the register 
pressure and the optimization based out of tree
Representation can use the above overlapping live ranges to take register 
pressure into account.

Thanks & Regards
Ajit

Re: Acceptance criteria for the git conversion

[Mikhail Maltsev]

On 09/01/2015 08:11 PM, Joseph Myers wrote:
> On Tue, 1 Sep 2015, Richard Earnshaw wrote:
> 
>> Renaming the files during the conversion is clearly *not* the right
>> thing to do: it would break all builds of old code.
> 
> Indeed.  Ideally the tree objects in the git conversion should have 
> exactly the same contents as SVN commits, and so be shared with the 
> git-svn history to reduce the eventual repository size (except where there 
> are defects in the git-svn history, or the git conversion fixes up cvs2svn 
> artifacts and so some old revisions end up more accurately reflecting old 
> history than the SVN repository does).

Actually, I did not propose to alter the repository history. I just meant to 
say that
if .c -> .cc renaming is still planned, it could be done right after 
conversion, as a
normal commit, or, perhaps series of commits on trunk and active development
(feature) branches.

-- 
Regards,
Mikhail Maltsev

Re: Acceptance criteria for the git conversion

[Joseph Myers]

On Tue, 1 Sep 2015, Mikhail Maltsev wrote:

> Actually, I did not propose to alter the repository history. I just 
> meant to say that if .c -> .cc renaming is still planned, it could be 
> done right after conversion, as a normal commit, or, perhaps series of 
> commits on trunk and active development (feature) branches.

If such a change were desired, "right after conversion" seems like a bad 
time for it - we should allow time for people to become familiar with 
working with the new repository, and to iron out any issues with hooks 
etc. that weren't found before the conversion went live, before doing any 
such major rearrangements of files.

-- 
Joseph S. Myers
jos...@codesourcery.com

RE: GTY / gengtype question - adding a new header file

[Matthew Fortune]

Steve Ellcey  writes:
> On Tue, 2015-09-01 at 10:13 +0200, Georg-Johann Lay wrote:
> 
> >
> > I'd have a look at what BEs are using non-default target_gtfiles.
> >
> > Johann
> 
> There are a few BEs that add a .c file to target_gtfiles, but no
> platforms that add a .h file to target_gtfiles.  I do see a number
> of platforms that define the machine_function structure in their header
> file (aarch64.h, pa.h, i386.h) instead of their .c file though.
> 
> Maybe that is a better way to go for MIPS instead of doing something
> completely new.  If I move machine_function, mips_frame_info,
> mips_int_mask, and mips_shadow_set from mips.c to mips.h then I could
> put my new machine specific pass in a separate .c file from mips.c and
> not need to do anything with target_gtfiles.  The only reason I didn't
> want to do this was so that machine_function wasn't visible to the rest
> of GCC but that doesn't seem to have been an issue for other targets.

Personally I quite like the idea of separating out code if at all possible
so having to expose a bit more of the MIPS backend internals does not
seem like too high a cost.

Matthew

gcc-5-20150901 is now available

[gccadmin]

Snapshot gcc-5-20150901 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/5-20150901/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 5 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-5-branch 
revision 227384

You'll find:

 gcc-5-20150901.tar.bz2   Complete GCC

  MD5=6bf228df69498262ec67498e3993819c
  SHA1=e56a320937e8f1ab0a2fc1585fda3cb194aa2829

Diffs from 5-20150825 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-5
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Re: reload question about unmet constraints

[Jeff Law]

On 09/01/2015 01:44 AM, DJ Delorie wrote:

Given this test case for rl78-elf:

extern __far int a, b;
void ffr (int x)
{
   a = b + x;
}

I'm trying to use this patch:

Index: gcc/config/rl78/rl78-virt.md
===
--- gcc/config/rl78/rl78-virt.md  (revision 227360)
+++ gcc/config/rl78/rl78-virt.md(working copy)
@@ -92,15 +92,15 @@
 ]
"rl78_virt_insns_ok ()"
"v.inc\t%0, %1, %2"
  )

  (define_insn "*add3_virt"
-  [(set (match_operand:QHI   0 "rl78_nonfar_nonimm_operand" "=vY,S")
-   (plus:QHI (match_operand:QHI 1 "rl78_nonfar_operand" "viY,0")
- (match_operand:QHI 2 "rl78_general_operand" "vim,i")))
+  [(set (match_operand:QHI   0 "rl78_nonimmediate_operand" "=vY,S,Wfr")
+   (plus:QHI (match_operand:QHI 1 "rl78_general_operand" "viY,0,0")
+ (match_operand:QHI 2 "rl78_general_operand" "vim,i,vi")))
 ]
"rl78_virt_insns_ok ()"
"v.add\t%0, %1, %2"
  )

  (define_insn "*sub3_virt"


To allow the rl78 port to generate the "Wfr/0/r" case (alternative 3).
(Wfr = far MEM, v = virtual regs).

I expected gcc to see that the operation doesn't meet the constraints,
and move operands into registers to make it work (alternative 1,
"v/v/v").
That'd be my expectation as well.  Note that addXX patterns may be 
special. I can recall a fair amount of pain with them on oddball ports.






Instead, it just complains and dies.

dj.c:42:1: error: insn does not satisfy its constraints:
  }
  ^
(insn 10 15 13 2 (set (mem/c:HI (reg:SI 8 r8) [1 a+0 S2 A16 AS2])
 (plus:HI (mem/c:HI (plus:HI (reg/f:HI 32 sp)
 (const_int 4 [0x4])) [1 x+0 S2 A16])
 (mem/c:HI (symbol_ref:SI ("b") ) [1 b+0 
S2 A16 AS2]))) dj.c:41 13 {*addhi3_virt}
  (nil))
dj.c:42:1: internal compiler error: in extract_constrain_insn, at recog.c:2200


Reloads for insn # 10
Reload 0: reload_in (SI) = (symbol_ref:SI ("a")  )
 V_REGS, RELOAD_FOR_INPUT (opnum = 0), inc by 2
 reload_in_reg: (symbol_ref:SI ("a")  )
 reload_reg_rtx: (reg:SI 8 r8)
Reload 1: reload_in (HI) = (mem/c:HI (plus:HI (reg/f:HI 32 sp)
 (const_int 4 [0x4])) 
[2 x+0 S2 A16])
 reload_out (HI) = (mem/c:HI (plus:HI (reg/f:HI 32 sp)
 (const_int 4 [0x4])) 
[2 x+0 S2 A16])
 V_REGS, RELOAD_OTHER (opnum = 1), optional
 reload_in_reg: (mem/c:HI (plus:HI (reg/f:HI 32 sp)
 (const_int 4 [0x4])) 
[2 x+0 S2 A16])
 reload_out_reg: (mem/c:HI (plus:HI (reg/f:HI 32 sp)
 (const_int 4 [0x4])) 
[2 x+0 S2 A16])
Reload 2: reload_in (HI) = (mem/c:HI (symbol_ref:SI ("b")  ) [2 b+0 S2 A16 AS2])
 V_REGS, RELOAD_FOR_INPUT (opnum = 2), optional
 reload_in_reg: (mem/c:HI (symbol_ref:SI ("b")  ) [2 b+0 S2 A16 AS2])
Note that reload 1 and reload 2 do not have a reload_reg_rtx.  My 
memories of reload are fading fast (thank goodness), but I believe 
that's an indication that it's not reloading into a hard register.


So I'd start with looking at find_reloads/push_reload and figure out why 
it's not getting a suitable register.  It might be good to know what 
alternative is being targeted by reload.  ie, you'll be looking at 
goal_alternative* in find_reloads.


Again, my memories are getting stale here, so double-check the meaning 
of reload_reg_rtx ;-)



jeff

Re: reload question about unmet constraints

[Jim Wilson]

On 09/01/2015 12:44 AM, DJ Delorie wrote:
> I expected gcc to see that the operation doesn't meet the constraints,
> and move operands into registers to make it work (alternative 1,
> "v/v/v").

It did match the first alternative (alternative 0), but it matched the
constraints Y/Y/m.  Operands 1 and 2 are OK, so don't need reloads.  It
did create optional reloads, which it always does for mem, but these
reloads are irrelevant.  The interesting one is for operand 0.  Since Y
accepts mem, and operand 0 is a mem but doesn't match, reload assumes
that we can fix it by reloading the address to make it an offsettable
address.  But a far mem is still not acceptable even with a reloaded
address, and you get an ICE.

Reload doesn't have any concept of two different kinds of memory
operands which can't be converted via reloads.  If the constraint
accepts mem, and we have a mem operand, then it will always assume that
the problem is with the address and reload it.

I don't think that there is an easy solution to this, but my reload
skills are a bit rusty too.

Jim

Re: Acceptance criteria for the git conversion

[David Malcolm]

On Tue, 2015-09-01 at 11:30 -0400, Eric S. Raymond wrote:
> Joseph Myers :
> > With 227369 revisions I don't think adding git-style summary lines is 
> > really practical without some very reliable automation to match commits to 
> > corresponding gcc-patches messages (whose Subject: headers would be the 
> > natural choice for such summary lines)
> 
> In this case you may be right.  Select =L tells me there are 101139
> commits wanting that sort of adjustment, which I think is at least
> 2.5x the bulk I've ever had to deal with before.
> 
> Still, if anyone else is brave enough to write a script that will munch
> through gcc-patches producing committer/date/subject-line triples, I'll
> give it a try.

I don't think committer/date/subject-line triples are adequate: the
dates are unlikely to match up, for one thing.

I think such a solution would need to somehow locate and match patches
themselves.

I was feeling brave, so I had a go at writing a scraper; see:
https://github.com/davidmalcolm/patch-finder
for what I have so far (tested with Python 2.7).

This can scrape the gcc-patches archives and locate mails containing
patches, extracting the patches (some of them anyway...).  The idea
would be to stuff the patches into some kind of big data store, and
somehow them try to locate them (perhaps within a rough date "window").

Does this seem like a viable approach?

Caution: this script performs numerous URL GETs on gcc.gnu.org;
it caches everything, but the first time you run it, the cache
will be cold.  (So please be careful!)

> About scale:  The largest repository I've dealt with before this was
> NetBSD, with a working set of 18GB, vs 45GB for this one.  The way 
> reposurgeon's
> internal representations work, working set is dominated by comment text.  So
> the GCC repo has about 2.5x the comment bulk of NetBSD.

RFC: adding Linux vsyscall-disable and similar backwards-incompatibility flags to ELF headers?

[Andy Lutomirski]

Hi all-

Linux has a handful of weird features that are only supported for
backwards compatibility.  The big one is the x86_64 vsyscall page, but
uselib probably belongs on the list, too, and we might end up with
more at some point.

I'd like to add a way that new programs can turn these features off.
In particular, I want the vsyscall page to be completely gone from the
perspective of any new enough program.  This is straightforward if we
add a system call to ask for the vsyscall page to be disabled, but I'm
wondering if we can come up with a non-syscall way to do it.

I think that the ideal behavior would be that anything linked against
a sufficiently new libc would be detected, but I don't see a good way
to do that using existing toolchain features.

Ideas?  We could add a new phdr for this, but then we'd need to play
linker script games, and I'm not sure that could be done in a clean,
extensible way.

--Andy

Re: Acceptance criteria for the git conversion

[Eric S. Raymond]

David Malcolm :
> > Still, if anyone else is brave enough to write a script that will munch
> > through gcc-patches producing committer/date/subject-line triples, I'll
> > give it a try.
> 
> I don't think committer/date/subject-line triples are adequate: the
> dates are unlikely to match up, for one thing.

Agreed. They're unlikely to match up exactly.

> I think such a solution would need to somehow locate and match patches
> themselves.
> 
> I was feeling brave, so I had a go at writing a scraper; see:
> https://github.com/davidmalcolm/patch-finder
> for what I have so far (tested with Python 2.7).
> 
> This can scrape the gcc-patches archives and locate mails containing
> patches, extracting the patches (some of them anyway...).  The idea
> would be to stuff the patches into some kind of big data store, and
> somehow them try to locate them (perhaps within a rough date "window").
> 
> Does this seem like a viable approach?

I think it's as good as we're likely to get given the data available.
-- 
http://www.catb.org/~esr/";>Eric S. Raymond

Re: RFC: adding Linux vsyscall-disable and similar backwards-incompatibility flags to ELF headers?

[Ian Lance Taylor]

On Tue, Sep 1, 2015 at 5:51 PM, Andy Lutomirski  wrote:
>
> Linux has a handful of weird features that are only supported for
> backwards compatibility.  The big one is the x86_64 vsyscall page, but
> uselib probably belongs on the list, too, and we might end up with
> more at some point.
>
> I'd like to add a way that new programs can turn these features off.
> In particular, I want the vsyscall page to be completely gone from the
> perspective of any new enough program.  This is straightforward if we
> add a system call to ask for the vsyscall page to be disabled, but I'm
> wondering if we can come up with a non-syscall way to do it.
>
> I think that the ideal behavior would be that anything linked against
> a sufficiently new libc would be detected, but I don't see a good way
> to do that using existing toolchain features.
>
> Ideas?  We could add a new phdr for this, but then we'd need to play
> linker script games, and I'm not sure that could be done in a clean,
> extensible way.

What sets up the vsyscall page, and what information does it have
before doing so?

I'm guessing it's the kernel that sets it up, and that all it can see
at that point is the program headers.

We could pass information using an appropriate note section.  My
recollection is that the linkers will turn an SHF_ALLOC note section
into a PT_NOTE program header.

Ian

Re: reload question about unmet constraints

[DJ Delorie]

> It did match the first alternative (alternative 0), but it matched the
> constraints Y/Y/m.

It shouldn't match Y as those are for near addresses (unless it's only
matching MEM==MEM), and the ones in the insn are far, but ...

> Reload doesn't have any concept of two different kinds of memory
> operands which can't be converted via reloads.  If the constraint
> accepts mem, and we have a mem operand, then it will always assume
> that the problem is with the address and reload it.

... this sounds like it could be a problem for me :-P

Re: reload question about unmet constraints

[Jim Wilson]

On Tue, Sep 1, 2015 at 6:20 PM, DJ Delorie  wrote:
>
>> It did match the first alternative (alternative 0), but it matched the
>> constraints Y/Y/m.
>
> It shouldn't match Y as those are for near addresses (unless it's only
> matching MEM==MEM), and the ones in the insn are far, but ...

Reload chooses the alternative that is the best match.  When using the
constraints Y/Y/m, 2 of the three operands match the constraints, so
this ends up being the best match.  It then tries to reload the far
mem to match Y, which fails, as all it knows how to do is reload a mem
address to make it match, which can't turn a far mem into a near mem.

You would need some way to indicate that while Y does accept a mem,
this particular mem can't be reloaded to match.  We don't have a way
to do that.

The Y constraint gets classified as contraint type CT_MEMORY.  In
find_reloads, in reload.c, there is a case CT_MEMORY, and it does
if (CONST_POOL_OK_P (operand_mode[i], operand)
|| MEM_P (operand))
  badop = 0;
constmemok = 1;
offmemok = 1;

Since the operand is a MEM, badop is set to zero.  That makes this
look like a good alternative.  You want badop to be left alone.  Also,
the fact that offmemok was set means that reload thinks that any mem
can be fixed by reloading the address to make it offsetable.  You
don't want offmemok set.  Without offmemok set, it should get reloaded
into a register, as reload will use the v constraint instead.

Jim

Re: RFC: adding Linux vsyscall-disable and similar backwards-incompatibility flags to ELF headers?

[Brian Gerst]

On Tue, Sep 1, 2015 at 8:51 PM, Andy Lutomirski  wrote:
> Hi all-
>
> Linux has a handful of weird features that are only supported for
> backwards compatibility.  The big one is the x86_64 vsyscall page, but
> uselib probably belongs on the list, too, and we might end up with
> more at some point.
>
> I'd like to add a way that new programs can turn these features off.
> In particular, I want the vsyscall page to be completely gone from the
> perspective of any new enough program.  This is straightforward if we
> add a system call to ask for the vsyscall page to be disabled, but I'm
> wondering if we can come up with a non-syscall way to do it.
>
> I think that the ideal behavior would be that anything linked against
> a sufficiently new libc would be detected, but I don't see a good way
> to do that using existing toolchain features.
>
> Ideas?  We could add a new phdr for this, but then we'd need to play
> linker script games, and I'm not sure that could be done in a clean,
> extensible way.


The vsyscall page is mapped in the fixmap region, which is shared
between all processes.  You can't turn it off for an individual
process.

--
Brian Gerst

Re: RFC: adding Linux vsyscall-disable and similar backwards-incompatibility flags to ELF headers?

[Andy Lutomirski]

On Sep 1, 2015 6:53 PM, "Brian Gerst"  wrote:
>
> On Tue, Sep 1, 2015 at 8:51 PM, Andy Lutomirski  wrote:
> > Hi all-
> >
> > Linux has a handful of weird features that are only supported for
> > backwards compatibility.  The big one is the x86_64 vsyscall page, but
> > uselib probably belongs on the list, too, and we might end up with
> > more at some point.
> >
> > I'd like to add a way that new programs can turn these features off.
> > In particular, I want the vsyscall page to be completely gone from the
> > perspective of any new enough program.  This is straightforward if we
> > add a system call to ask for the vsyscall page to be disabled, but I'm
> > wondering if we can come up with a non-syscall way to do it.
> >
> > I think that the ideal behavior would be that anything linked against
> > a sufficiently new libc would be detected, but I don't see a good way
> > to do that using existing toolchain features.
> >
> > Ideas?  We could add a new phdr for this, but then we'd need to play
> > linker script games, and I'm not sure that could be done in a clean,
> > extensible way.
>
>
> The vsyscall page is mapped in the fixmap region, which is shared
> between all processes.  You can't turn it off for an individual
> process.

Why not?

We already emulate all attempts to execute it, and that's trivial to
turn of per process.  Project Zero pointed out that read access is a
problem, too, but we can flip the U/S bit in the pgd once we evict
pvclock from the fixmap.

And we definitely need to evict pvclock from the fixmap regardless.

--Andy

Re: RFC: adding Linux vsyscall-disable and similar backwards-incompatibility flags to ELF headers?

[Andy Lutomirski]

On Sep 1, 2015 6:12 PM, "Ian Lance Taylor"  wrote:
>
> On Tue, Sep 1, 2015 at 5:51 PM, Andy Lutomirski  wrote:
> >
> > Linux has a handful of weird features that are only supported for
> > backwards compatibility.  The big one is the x86_64 vsyscall page, but
> > uselib probably belongs on the list, too, and we might end up with
> > more at some point.
> >
> > I'd like to add a way that new programs can turn these features off.
> > In particular, I want the vsyscall page to be completely gone from the
> > perspective of any new enough program.  This is straightforward if we
> > add a system call to ask for the vsyscall page to be disabled, but I'm
> > wondering if we can come up with a non-syscall way to do it.
> >
> > I think that the ideal behavior would be that anything linked against
> > a sufficiently new libc would be detected, but I don't see a good way
> > to do that using existing toolchain features.
> >
> > Ideas?  We could add a new phdr for this, but then we'd need to play
> > linker script games, and I'm not sure that could be done in a clean,
> > extensible way.
>
> What sets up the vsyscall page, and what information does it have
> before doing so?
>
> I'm guessing it's the kernel that sets it up, and that all it can see
> at that point is the program headers.

Currently it's global and nothing thinks about it per-process at all.
The kernel can do whatever it likes going forward, subject to
backwards compatibility.  Doing something at ELF load time is probably
the right approach.

>
> We could pass information using an appropriate note section.  My
> recollection is that the linkers will turn an SHF_ALLOC note section
> into a PT_NOTE program header.

Oh, interesting.  I'll check that.  Glibc and competitors could add
notes to their statically-linked bits.

The unpleasant case is a new dynamic binary linked against an old
libc, but that might be irrelevant in practice.  After all, I think
that a lot of libc competitors never supported the vsyscall page at
all, and even glibc isn't really backwards compatible that way.

We could also require that both the binary and interpreter have the
note, which would more or less solve the backwards compatibility
issue.

--Andy

Re: [musl] RFC: adding Linux vsyscall-disable and similar backwards-incompatibility flags to ELF headers?

[Rich Felker]

On Tue, Sep 01, 2015 at 05:51:44PM -0700, Andy Lutomirski wrote:
> Hi all-
> 
> Linux has a handful of weird features that are only supported for
> backwards compatibility.  The big one is the x86_64 vsyscall page, but
> uselib probably belongs on the list, too, and we might end up with
> more at some point.
> 
> I'd like to add a way that new programs can turn these features off.
> In particular, I want the vsyscall page to be completely gone from the
> perspective of any new enough program.  This is straightforward if we
> add a system call to ask for the vsyscall page to be disabled, but I'm
> wondering if we can come up with a non-syscall way to do it.
> 
> I think that the ideal behavior would be that anything linked against
> a sufficiently new libc would be detected, but I don't see a good way
> to do that using existing toolchain features.
> 
> Ideas?  We could add a new phdr for this, but then we'd need to play
> linker script games, and I'm not sure that could be done in a clean,
> extensible way.

Is there a practical problem you're trying to solve? My understanding
is that the vsyscall nonsense is fully emulated now and that the ways
it could be used as an attack vector have been mitigated.

If this is not the case, I have what sounds like an elegant solution,
if it works: presumably affected versions of glibc that used this used
it for all syscalls, so if the process has made any normal syscalls
before using the vsyscall addresses, you can assume it's a bug/attack
and and just raise SIGSEGV. If there are corner cases this doesn't
cover, maybe the approach can still be adapted to work; it's cleaner
than introducing header cruft, IMO.

Rich

Re: [musl] RFC: adding Linux vsyscall-disable and similar backwards-incompatibility flags to ELF headers?

[Andy Lutomirski]

On Tue, Sep 1, 2015 at 7:54 PM, Rich Felker  wrote:
> On Tue, Sep 01, 2015 at 05:51:44PM -0700, Andy Lutomirski wrote:
>> Hi all-
>>
>> Linux has a handful of weird features that are only supported for
>> backwards compatibility.  The big one is the x86_64 vsyscall page, but
>> uselib probably belongs on the list, too, and we might end up with
>> more at some point.
>>
>> I'd like to add a way that new programs can turn these features off.
>> In particular, I want the vsyscall page to be completely gone from the
>> perspective of any new enough program.  This is straightforward if we
>> add a system call to ask for the vsyscall page to be disabled, but I'm
>> wondering if we can come up with a non-syscall way to do it.
>>
>> I think that the ideal behavior would be that anything linked against
>> a sufficiently new libc would be detected, but I don't see a good way
>> to do that using existing toolchain features.
>>
>> Ideas?  We could add a new phdr for this, but then we'd need to play
>> linker script games, and I'm not sure that could be done in a clean,
>> extensible way.
>
> Is there a practical problem you're trying to solve? My understanding
> is that the vsyscall nonsense is fully emulated now and that the ways
> it could be used as an attack vector have been mitigated.

They've been mostly mitigated, but not fully.  See:

http://googleprojectzero.blogspot.com/2015/08/three-bypasses-and-fix-for-one-of.html

I'm also waiting for someone to find an exploit that uses one of the
vsyscalls as a ROP gadget.

>
> If this is not the case, I have what sounds like an elegant solution,
> if it works: presumably affected versions of glibc that used this used
> it for all syscalls, so if the process has made any normal syscalls
> before using the vsyscall addresses, you can assume it's a bug/attack
> and and just raise SIGSEGV. If there are corner cases this doesn't
> cover, maybe the approach can still be adapted to work; it's cleaner
> than introducing header cruft, IMO.

Unfortunately, I don't think this will work.  It's never been possible
to use the vsyscalls for anything other than gettimeofday, time, or
getcpu, so I doubt we can detect affected glibc versions that way.

--Andy

Re: [musl] RFC: adding Linux vsyscall-disable and similar backwards-incompatibility flags to ELF headers?

[Rich Felker]

On Tue, Sep 01, 2015 at 08:39:27PM -0700, Andy Lutomirski wrote:
> On Tue, Sep 1, 2015 at 7:54 PM, Rich Felker  wrote:
> > On Tue, Sep 01, 2015 at 05:51:44PM -0700, Andy Lutomirski wrote:
> >> Hi all-
> >>
> >> Linux has a handful of weird features that are only supported for
> >> backwards compatibility.  The big one is the x86_64 vsyscall page, but
> >> uselib probably belongs on the list, too, and we might end up with
> >> more at some point.
> >>
> >> I'd like to add a way that new programs can turn these features off.
> >> In particular, I want the vsyscall page to be completely gone from the
> >> perspective of any new enough program.  This is straightforward if we
> >> add a system call to ask for the vsyscall page to be disabled, but I'm
> >> wondering if we can come up with a non-syscall way to do it.
> >>
> >> I think that the ideal behavior would be that anything linked against
> >> a sufficiently new libc would be detected, but I don't see a good way
> >> to do that using existing toolchain features.
> >>
> >> Ideas?  We could add a new phdr for this, but then we'd need to play
> >> linker script games, and I'm not sure that could be done in a clean,
> >> extensible way.
> >
> > Is there a practical problem you're trying to solve? My understanding
> > is that the vsyscall nonsense is fully emulated now and that the ways
> > it could be used as an attack vector have been mitigated.
> 
> They've been mostly mitigated, but not fully.  See:
> 
> http://googleprojectzero.blogspot.com/2015/08/three-bypasses-and-fix-for-one-of.html

That looks like it would be mitigated by not having any mapping there
at all and having the kernel just catch the page fault and emulate
rather than filling it with trapping opcodes for the kernel to catch.

> I'm also waiting for someone to find an exploit that uses one of the
> vsyscalls as a ROP gadget.

This sounds more plausible. gettimeofday actually writes to memory
pointed to by its arguments. The others look benign.

> > If this is not the case, I have what sounds like an elegant solution,
> > if it works: presumably affected versions of glibc that used this used
> > it for all syscalls, so if the process has made any normal syscalls
> > before using the vsyscall addresses, you can assume it's a bug/attack
> > and and just raise SIGSEGV. If there are corner cases this doesn't
> > cover, maybe the approach can still be adapted to work; it's cleaner
> > than introducing header cruft, IMO.
> 
> Unfortunately, I don't think this will work.  It's never been possible
> to use the vsyscalls for anything other than gettimeofday, time, or
> getcpu, so I doubt we can detect affected glibc versions that way.

I thought the idea of the old vsyscall was that you always call it
rather than using a syscall instruction and it decides whether it can
do it in userspace or needs to make a real syscall. But if it was only
called from certain places, then yes, I think you're right that my
approach doesn't work.

Rich

Re: [musl] RFC: adding Linux vsyscall-disable and similar backwards-incompatibility flags to ELF headers?

[Andy Lutomirski]

On Tue, Sep 1, 2015 at 9:18 PM, Rich Felker  wrote:
> On Tue, Sep 01, 2015 at 08:39:27PM -0700, Andy Lutomirski wrote:
>> On Tue, Sep 1, 2015 at 7:54 PM, Rich Felker  wrote:
>> > On Tue, Sep 01, 2015 at 05:51:44PM -0700, Andy Lutomirski wrote:
>> >> Hi all-
>> >>
>> >> Linux has a handful of weird features that are only supported for
>> >> backwards compatibility.  The big one is the x86_64 vsyscall page, but
>> >> uselib probably belongs on the list, too, and we might end up with
>> >> more at some point.
>> >>
>> >> I'd like to add a way that new programs can turn these features off.
>> >> In particular, I want the vsyscall page to be completely gone from the
>> >> perspective of any new enough program.  This is straightforward if we
>> >> add a system call to ask for the vsyscall page to be disabled, but I'm
>> >> wondering if we can come up with a non-syscall way to do it.
>> >>
>> >> I think that the ideal behavior would be that anything linked against
>> >> a sufficiently new libc would be detected, but I don't see a good way
>> >> to do that using existing toolchain features.
>> >>
>> >> Ideas?  We could add a new phdr for this, but then we'd need to play
>> >> linker script games, and I'm not sure that could be done in a clean,
>> >> extensible way.
>> >
>> > Is there a practical problem you're trying to solve? My understanding
>> > is that the vsyscall nonsense is fully emulated now and that the ways
>> > it could be used as an attack vector have been mitigated.
>>
>> They've been mostly mitigated, but not fully.  See:
>>
>> http://googleprojectzero.blogspot.com/2015/08/three-bypasses-and-fix-for-one-of.html
>
> That looks like it would be mitigated by not having any mapping there
> at all and having the kernel just catch the page fault and emulate
> rather than filling it with trapping opcodes for the kernel to catch.
>

Oddly, that causes a compatibility problem.  There's a program called
pin that does dynamic instrumentation and actually expects to be able
to read the targets of calls.  The way that Linux handles this now is
to put a literal mov $NR, %rax; syscall; ret sequence at the syscall
address but to mark the whole page NX so that any attempt to call it
traps.  The trap gets fixed up if the call looks valid (properly
aligned, etc) and the process gets SIGSEGV if not.

This caught me by surprise when I implemented vsyscall emulation the first time.

>> I'm also waiting for someone to find an exploit that uses one of the
>> vsyscalls as a ROP gadget.
>
> This sounds more plausible. gettimeofday actually writes to memory
> pointed to by its arguments. The others look benign.
>
>> > If this is not the case, I have what sounds like an elegant solution,
>> > if it works: presumably affected versions of glibc that used this used
>> > it for all syscalls, so if the process has made any normal syscalls
>> > before using the vsyscall addresses, you can assume it's a bug/attack
>> > and and just raise SIGSEGV. If there are corner cases this doesn't
>> > cover, maybe the approach can still be adapted to work; it's cleaner
>> > than introducing header cruft, IMO.
>>
>> Unfortunately, I don't think this will work.  It's never been possible
>> to use the vsyscalls for anything other than gettimeofday, time, or
>> getcpu, so I doubt we can detect affected glibc versions that way.
>
> I thought the idea of the old vsyscall was that you always call it
> rather than using a syscall instruction and it decides whether it can
> do it in userspace or needs to make a real syscall. But if it was only
> called from certain places, then yes, I think you're right that my
> approach doesn't work.

No, it's actually just three separate functions, one for each of
gettimeofday, time, and getcpu.

--Andy

Re: [musl] RFC: adding Linux vsyscall-disable and similar backwards-incompatibility flags to ELF headers?

[Rich Felker]

On Tue, Sep 01, 2015 at 09:32:22PM -0700, Andy Lutomirski wrote:
> On Tue, Sep 1, 2015 at 9:18 PM, Rich Felker  wrote:
> > On Tue, Sep 01, 2015 at 08:39:27PM -0700, Andy Lutomirski wrote:
> >> On Tue, Sep 1, 2015 at 7:54 PM, Rich Felker  wrote:
> >> > On Tue, Sep 01, 2015 at 05:51:44PM -0700, Andy Lutomirski wrote:
> >> >> Hi all-
> >> >>
> >> >> Linux has a handful of weird features that are only supported for
> >> >> backwards compatibility.  The big one is the x86_64 vsyscall page, but
> >> >> uselib probably belongs on the list, too, and we might end up with
> >> >> more at some point.
> >> >>
> >> >> I'd like to add a way that new programs can turn these features off.
> >> >> In particular, I want the vsyscall page to be completely gone from the
> >> >> perspective of any new enough program.  This is straightforward if we
> >> >> add a system call to ask for the vsyscall page to be disabled, but I'm
> >> >> wondering if we can come up with a non-syscall way to do it.
> >> >>
> >> >> I think that the ideal behavior would be that anything linked against
> >> >> a sufficiently new libc would be detected, but I don't see a good way
> >> >> to do that using existing toolchain features.
> >> >>
> >> >> Ideas?  We could add a new phdr for this, but then we'd need to play
> >> >> linker script games, and I'm not sure that could be done in a clean,
> >> >> extensible way.
> >> >
> >> > Is there a practical problem you're trying to solve? My understanding
> >> > is that the vsyscall nonsense is fully emulated now and that the ways
> >> > it could be used as an attack vector have been mitigated.
> >>
> >> They've been mostly mitigated, but not fully.  See:
> >>
> >> http://googleprojectzero.blogspot.com/2015/08/three-bypasses-and-fix-for-one-of.html
> >
> > That looks like it would be mitigated by not having any mapping there
> > at all and having the kernel just catch the page fault and emulate
> > rather than filling it with trapping opcodes for the kernel to catch.
> >
> 
> Oddly, that causes a compatibility problem.  There's a program called
> pin that does dynamic instrumentation and actually expects to be able
> to read the targets of calls.  The way that Linux handles this now is

Um, do people seriously need to do this dynamic instrumentation on
ancient obsolete binaries? This sounds to me like confused
requirements.

Rich

Re: [musl] RFC: adding Linux vsyscall-disable and similar backwards-incompatibility flags to ELF headers?

[Andy Lutomirski]

On Tue, Sep 1, 2015 at 9:55 PM, Rich Felker  wrote:
> On Tue, Sep 01, 2015 at 09:32:22PM -0700, Andy Lutomirski wrote:
>> On Tue, Sep 1, 2015 at 9:18 PM, Rich Felker  wrote:
>> > On Tue, Sep 01, 2015 at 08:39:27PM -0700, Andy Lutomirski wrote:
>> >> On Tue, Sep 1, 2015 at 7:54 PM, Rich Felker  wrote:
>> >> > On Tue, Sep 01, 2015 at 05:51:44PM -0700, Andy Lutomirski wrote:
>> >> >> Hi all-
>> >> >>
>> >> >> Linux has a handful of weird features that are only supported for
>> >> >> backwards compatibility.  The big one is the x86_64 vsyscall page, but
>> >> >> uselib probably belongs on the list, too, and we might end up with
>> >> >> more at some point.
>> >> >>
>> >> >> I'd like to add a way that new programs can turn these features off.
>> >> >> In particular, I want the vsyscall page to be completely gone from the
>> >> >> perspective of any new enough program.  This is straightforward if we
>> >> >> add a system call to ask for the vsyscall page to be disabled, but I'm
>> >> >> wondering if we can come up with a non-syscall way to do it.
>> >> >>
>> >> >> I think that the ideal behavior would be that anything linked against
>> >> >> a sufficiently new libc would be detected, but I don't see a good way
>> >> >> to do that using existing toolchain features.
>> >> >>
>> >> >> Ideas?  We could add a new phdr for this, but then we'd need to play
>> >> >> linker script games, and I'm not sure that could be done in a clean,
>> >> >> extensible way.
>> >> >
>> >> > Is there a practical problem you're trying to solve? My understanding
>> >> > is that the vsyscall nonsense is fully emulated now and that the ways
>> >> > it could be used as an attack vector have been mitigated.
>> >>
>> >> They've been mostly mitigated, but not fully.  See:
>> >>
>> >> http://googleprojectzero.blogspot.com/2015/08/three-bypasses-and-fix-for-one-of.html
>> >
>> > That looks like it would be mitigated by not having any mapping there
>> > at all and having the kernel just catch the page fault and emulate
>> > rather than filling it with trapping opcodes for the kernel to catch.
>> >
>>
>> Oddly, that causes a compatibility problem.  There's a program called
>> pin that does dynamic instrumentation and actually expects to be able
>> to read the targets of calls.  The way that Linux handles this now is
>
> Um, do people seriously need to do this dynamic instrumentation on
> ancient obsolete binaries? This sounds to me like confused
> requirements.

Unclear.  They certainly did, and I got a bug report, the first time
around.  That was a couple years ago.

I suppose we could have a sysctl that you need to set to enable that
use case.  OTOH, I think that, as long as we have a way to distinguish
new and old binaries, it's not that much harder to twiddle vsyscall
readability per process than it is to twiddle vsyscall executability
per process.

--Andy

Re: [musl] RFC: adding Linux vsyscall-disable and similar backwards-incompatibility flags to ELF headers?

[Rich Felker]

On Tue, Sep 01, 2015 at 10:03:27PM -0700, Andy Lutomirski wrote:
> On Tue, Sep 1, 2015 at 9:55 PM, Rich Felker  wrote:
> > On Tue, Sep 01, 2015 at 09:32:22PM -0700, Andy Lutomirski wrote:
> >> On Tue, Sep 1, 2015 at 9:18 PM, Rich Felker  wrote:
> >> > On Tue, Sep 01, 2015 at 08:39:27PM -0700, Andy Lutomirski wrote:
> >> >> On Tue, Sep 1, 2015 at 7:54 PM, Rich Felker  wrote:
> >> >> > On Tue, Sep 01, 2015 at 05:51:44PM -0700, Andy Lutomirski wrote:
> >> >> >> Hi all-
> >> >> >>
> >> >> >> Linux has a handful of weird features that are only supported for
> >> >> >> backwards compatibility.  The big one is the x86_64 vsyscall page, 
> >> >> >> but
> >> >> >> uselib probably belongs on the list, too, and we might end up with
> >> >> >> more at some point.
> >> >> >>
> >> >> >> I'd like to add a way that new programs can turn these features off.
> >> >> >> In particular, I want the vsyscall page to be completely gone from 
> >> >> >> the
> >> >> >> perspective of any new enough program.  This is straightforward if we
> >> >> >> add a system call to ask for the vsyscall page to be disabled, but 
> >> >> >> I'm
> >> >> >> wondering if we can come up with a non-syscall way to do it.
> >> >> >>
> >> >> >> I think that the ideal behavior would be that anything linked against
> >> >> >> a sufficiently new libc would be detected, but I don't see a good way
> >> >> >> to do that using existing toolchain features.
> >> >> >>
> >> >> >> Ideas?  We could add a new phdr for this, but then we'd need to play
> >> >> >> linker script games, and I'm not sure that could be done in a clean,
> >> >> >> extensible way.
> >> >> >
> >> >> > Is there a practical problem you're trying to solve? My understanding
> >> >> > is that the vsyscall nonsense is fully emulated now and that the ways
> >> >> > it could be used as an attack vector have been mitigated.
> >> >>
> >> >> They've been mostly mitigated, but not fully.  See:
> >> >>
> >> >> http://googleprojectzero.blogspot.com/2015/08/three-bypasses-and-fix-for-one-of.html
> >> >
> >> > That looks like it would be mitigated by not having any mapping there
> >> > at all and having the kernel just catch the page fault and emulate
> >> > rather than filling it with trapping opcodes for the kernel to catch.
> >> >
> >>
> >> Oddly, that causes a compatibility problem.  There's a program called
> >> pin that does dynamic instrumentation and actually expects to be able
> >> to read the targets of calls.  The way that Linux handles this now is
> >
> > Um, do people seriously need to do this dynamic instrumentation on
> > ancient obsolete binaries? This sounds to me like confused
> > requirements.
> 
> Unclear.  They certainly did, and I got a bug report, the first time
> around.  That was a couple years ago.
> 
> I suppose we could have a sysctl that you need to set to enable that
> use case.  OTOH, I think that, as long as we have a way to distinguish
> new and old binaries, it's not that much harder to twiddle vsyscall
> readability per process than it is to twiddle vsyscall executability
> per process.

But we don't have a (reasonable) way to distinguish new and old
binaries, at least not at the right point in history. If we're adding
a new header or whatnot, only bleeding-edge binaries will benefit from
it. All existing binaries from the past N years that don't need the
vsyscall nonsense will still get it unnecessarily, and still be
subject to the risks.

This has me wondering if there's any point in trying to solve the
problem on the granularity of individual programs. Users running
all-new binaries (that would benefit from a header flag) can just
remove vsyscall support entirely from their kernels. Users with a mix
binaries of various ages will likely still have the vsyscall risk in
most programs, _including_ many newer binaries that have no use for
vsyscall but lack the new header.

BTW, since the only calls to vsyscall are from glibc, it seems to me
that the only ways vsyscall can be needed are:

1. The user is running old glibc, in which case all dynamic-linked
   programs need it.

2. The user is running old static-linked glibc binaries. Almost nobody
   does this. During the era of vsyscall, static linking was all but
   deprecated.

3. The user is running old binaries using a custom library path with
   old glibc in it. This is almost certainly just a bogus setup since
   glibc's symbol versioning is supposed to make old binaries run fine
   with a newer libc.so.

None of these seem to be use cases that we should be engineering
complex solutions for. For case 1, the solution wouldn't help anyway
since all programs need vsyscall. For cases 2 and 3, if the user wants
to harden their system so that newer binaries are not affected by
vsyscall, they should just remove vsyscall and fix their old
binaries/libraries. In case 2, in particular, you can assume the
ability to re-link with an updated glibc; otherwise, there's an LGPL
violation going on.

Rich