Aliasing rules for unannotated SYMBOL_REFs

[Richard Sandiford]

TL;DR: if we have two bare SYMBOL_REFs X and Y, neither of which have an
associated source-level decl and neither of which are in an anchor block:

(Q1) can a valid byte access at X+C alias a valid byte access at Y+C?

(Q2) can a valid byte access at X+C1 alias a valid byte access at Y+C2,
 C1 != C2?

Also:

(Q3) If X has a source-level decl and Y doesn't, and neither of them are
 in an anchor block, can valid accesses based on X alias valid accesses
 based on Y?

(well, OK, that wasn't too short either...)

The reason for asking is that memrefs_conflict_p seems to have an
odd structure.  It first checks whether two addresses based on
SYMBOL_REFs refer to the same object, with a tristate result:

  int cmp = compare_base_symbol_refs (x,y);

AFAICT the return values mean:

  1: the SYMBOL_REFs are known to be equal
  0: in-range accesses based on X cannot alias in-range accesses based on Y
 -1: all other cases

If the addresses are known to be equal, we can use an offset-based check:

  /* If both decls are the same, decide by offsets.  */
  if (cmp == 1)
return offset_overlap_p (c, xsize, ysize);

This part seems obvious enough.  But then, apart from the special case of
forced address alignment, we use an offset-based check even for cmp==-1:

  /* Assume a potential overlap for symbolic addresses that went
 through alignment adjustments (i.e., that have negative
 sizes), because we can't know how far they are from each
 other.  */
  if (maybe_lt (xsize, 0) || maybe_lt (ysize, 0))
return -1;
  /* If decls are different or we know by offsets that there is no overlap,
 we win.  */
  if (!cmp || !offset_overlap_p (c, xsize, ysize))
return 0;

So we seem to be taking cmp==-1 to mean that although we don't know
the relationship between the symbols, it must be the case that either
(a) the symbols are equal (e.g. via aliasing) or (b) the accesses are
to non-overlapping objects.  In other words, one of the situations
described by cmp==1 or cmp==0 must be true, but we don't know which
at compile time.

This means that in practice, the answer to (Q1) appears to be "yes"
but the answer to (Q2) appears to be "no".

This somewhat contradicts:

  /* In general we assume that memory locations pointed to by different labels
 may overlap in undefined ways.  */
  return -1;

at the end of compare_base_symbol_refs, which seems to be saying
that the answer to (Q2) ought to be "yes" instead.  Which is right?

In PR92294 we have a symbol X at ANCHOR+OFFSET that's preemptible.
Under the (Q1)==yes/(Q2)==no assumption, cmp==-1 means that either
(a) X = ANCHOR+OFFSET or (b) X and ANCHOR reference non-overlapping
objects.  So we should take the offset into account when doing:

  if (!cmp || !offset_overlap_p (c, xsize, ysize))
return 0;

Let's call this FIX1.

But that then brings us to: why does memrefs_conflict_p return -1
when one symbol X has a decl and the other symbol Y doesn't, and neither
of them are block symbols?  Is the answer to (Q3) that we allow equality
but not overlap here too?  E.g. a linker script could define Y to X but
not to a region that contains X at a nonzero offset?

If so, and if one symbol X is an anchor symbol and the other Y has no
information, we have to assume that the linker script could point Y at
any decl in X's block (even if it can't point Y at a constant offset
from those decls).  So we'd need to skip the offset-based check in that
case at least, unless perhaps the block has a single decl.  Let's call
this FIX2.

FIX2 seems like a strange special case though.

On the other hand, if the answer to (Q2) is supposed to be "yes",
I guess we should remove the cmp==-1 offset check altogether.
Let's call this FIX3.

So it looks like there are several "sensible" possibilities:

  Q1  Q2  Q3  | Fixes   | Notes
  +-+--
  yes no  yes | FIX1 + FIX2 | apparently the status quo
  yes yes yes | FIX3|
  yes no  no  | FIX1| (N1)
  yes yes no  | FIX3| (N1)
  no  no  no  | other   | (N2)

(N1) the x_decl && !y_decl and !x_decl && y_decl cases in
 compare_base_symbol_refs are too conservative

(N2) several compare_base_symbol_refs cases are too conservative

Sorry for the overblown write-up.  I was just trying to capture all
the twisty corners I'd turned while working on this PR...

Thanks,
Richard

musl, glibc and ideal place for __stack_chk_fail_local

[Sergei Trofimovich]

[ sending it to musl, glibc and gcc devel mailing list as we need
  to build a consensus across the projects ]

To support smash stack protection gcc emits __stack_chk_fail
calls on all targets. On top of that gcc emits __stack_chk_fail_local
calls at least on i386 and powerpc:
https://bugs.gentoo.org/706210#c9

gcc can either use libssp/libssp_nonshared fallback or rely on libc
to provide __stack_chk_fail. Where ideally should gcc pick
__stack_chk_fail_local?

Looks like gcc/glibc and musl disagree on that:
- gcc: gcc either provides it from libssp_nonshared.a if libc has
  no ssp support or pulls it from libc
- glibc: provides both __stack_chk_fail (deault) and
  __stack_chk_fail_local (avoid PLT) symbols.
  __stack_chk_fail_local comes from libc_nonshared.a and is
  added to linker script as: $ cat /usr/lib/libc.so
OUTPUT_FORMAT(elf32-i386)
GROUP ( /lib/libc.so.6 /usr/lib/libc_nonshared.a  AS_NEEDED ( 
/lib/ld-linux.so.2 ) )
- musl: provides only __stack_chk_fail (default) and
  refuses to provide __stack_chk_fail_local:
  https://www.openwall.com/lists/musl/2018/09/11/2

This makes musl effectively not support ssp on i386 and probably powerpc.

Currently gcc's assumption is that musl supports ssp symbols
from libc on all targets:
   
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/configure.ac;h=a7521ee99436a7c12159bdde0471dc66d3c4288e;hb=HEAD#l6079

  6088 case "$target" in
  6089*-*-musl*)
  6090  # All versions of musl provide stack protector
  6091  gcc_cv_libc_provides_ssp=yes;;

Clearly that assumption is not correct as __stack_chk_fail_local
is not provided by musl and linking fails.

This sounds like a expectation mismatch between gcc and musl
of what it takes to implement an ssp interface.

What should we do to make it fixed long term and short term?

Long term:

Is there a vision of perfect end state agreed with gcc/glibc/musl
folk so we could just implement it? If there is none let's try to
form one.

My understanding of requirements for libc that exposes ssp support:
- __stack_chk_fail is implemented as a default symbol
- __stack_chk_fail_local is implemented as a local symbol to avoid PLT.
  (Why is it important? To avoid use of potentially already broken stack?)

My understanding of possible perfect end state:
1. All libcs are required to somehow provide both __stack_chk_fail
   and __stack_chk_fail_local: be it linker script, crt*.o files or an extra
   libc_nonshared.a which gcc explicitly uses. Which one is best?
2. All libcs are required to provide only __stack_chk_fail and gcc always
   provides __stack_chk_local from libgcc.a, or from new libgcc_ssp.a.
   Evntually glibc drops it's __stack_chk_fail definition.
3. Your variant.

How do you gcc/glibc/musl folk see it? Once we decide I'll file bugs
against agreed projects. At least gcc could explicitly document the
interface.

Short term:

While the above is not addressed what should we do about musl in gcc?

Should gcc stop trying use musl on i386/powerpc here:
  6088 case "$target" in
  6089*-*-musl*)
  6090  # All versions of musl provide stack protector
  6091  gcc_cv_libc_provides_ssp=yes;;
and fall back to libssp instead?

If it makes sense I'll create a bug against gcc.

Thanks!

-- 

  Sergei

Git push account

[Feng Xue OS]

Which account should I use to push my local patch to git repo of gcc? 
I have a sourceware account that works for svn, but now it doesn't for git.
Actually both below commands were tried, but failed.
  git push ssh://f...@sourceware.org/gcc/gcc.git ..., 
  git push ssh://f...@gcc.gnu.org/gcc/gcc.git ...

Thansk,
Feng

Re: Git push account

[Andreas Schwab]

On Jan 25 2020, Feng Xue OS wrote:

> Which account should I use to push my local patch to git repo of gcc? 

See .

> I have a sourceware account that works for svn, but now it doesn't for git.
> Actually both below commands were tried, but failed.
>   git push ssh://f...@sourceware.org/gcc/gcc.git ..., 
>   git push ssh://f...@gcc.gnu.org/gcc/gcc.git ...

Replace /gcc/ by /git/.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: Git push account

[Feng Xue OS]

Thanks.

Feng

From: Andreas Schwab 
Sent: Saturday, January 25, 2020 10:07 PM
To: Feng Xue OS
Cc: gcc@gcc.gnu.org
Subject: Re: Git push account

On Jan 25 2020, Feng Xue OS wrote:

> Which account should I use to push my local patch to git repo of gcc?

See .

> I have a sourceware account that works for svn, but now it doesn't for git.
> Actually both below commands were tried, but failed.
>   git push ssh://f...@sourceware.org/gcc/gcc.git ...,
>   git push ssh://f...@gcc.gnu.org/gcc/gcc.git ...

Replace /gcc/ by /git/.

Andreas.

--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: Git ChangeLog policy for GCC Testsuite inquiry

[Nathan Sidwell]

On 1/24/20 4:36 PM, Jeff Law wrote:

On Fri, 2020-01-24 at 20:32 +0100, Eric Botcazou wrote:

I strongly prefer to move towards relying on the git log.


In my experience the output of git log is a total mess so cannot replace
ChangeLogs.  But we can well decide to drop ChangeLog for the testsuite.

Well, glibc has moved to extracting them from git, building policies
and scripts around that.  I'm pretty sure other significant projecs are
also extracting their ChangeLogs from git.

We could do the same, selecting some magic date as the cutover point
after which future ChangeLogs are extracted from GIT.  In fact, that's
precisely what I'd like to see us do.


The GCC10 release date would seem a good point to do this.  That gives us around 
3 months to figure the details (and get stakeholder buy-in)


nathan

--
Nathan Sidwell

Re: [musl] musl, glibc and ideal place for __stack_chk_fail_local

[Rich Felker]

On Sat, Jan 25, 2020 at 10:53:31AM +, Sergei Trofimovich wrote:
> [ sending it to musl, glibc and gcc devel mailing list as we need
>   to build a consensus across the projects ]
> 
> To support smash stack protection gcc emits __stack_chk_fail
> calls on all targets. On top of that gcc emits __stack_chk_fail_local
> calls at least on i386 and powerpc:
> https://bugs.gentoo.org/706210#c9
> 
> gcc can either use libssp/libssp_nonshared fallback or rely on libc
> to provide __stack_chk_fail. Where ideally should gcc pick
> __stack_chk_fail_local?

*Ideally*, GCC would emit it as a linkonce function section in every
file that used it, the same way it does for __x86.get_pc_thunk.bx,
etc. But that's not going to happen in old GCC versions so it's not a
real solution even if new GCC were improved to do that.

Second-best would be for __stack_chk_fail_local to be in the
static-only part of libgcc. It's the same kind of compiler glue. This
is plausible to patch into any GCC version when building.

In reality, the path of least resistance is just continuing to have it
in libssp_nonshared.a; this is what all the distros do. All it
requires is patching the GCC specs so that -lssp_nonshared is always
passed.

> Looks like gcc/glibc and musl disagree on that:
> - gcc: gcc either provides it from libssp_nonshared.a if libc has
>   no ssp support or pulls it from libc
> - glibc: provides both __stack_chk_fail (deault) and
>   __stack_chk_fail_local (avoid PLT) symbols.
>   __stack_chk_fail_local comes from libc_nonshared.a and is
>   added to linker script as: $ cat /usr/lib/libc.so
> OUTPUT_FORMAT(elf32-i386)
> GROUP ( /lib/libc.so.6 /usr/lib/libc_nonshared.a  AS_NEEDED ( 
> /lib/ld-linux.so.2 ) )

There's no good reason for it to come from a "nonshared" lib file
provided by libc rather than by the compiler. It's compiler ABI glue
between the public API/ABI (__stack_chk_fail) and the PIC callers that
don't want to be burdened by the GOT pointer setup to be able to call
thru PLT.

> - musl: provides only __stack_chk_fail (default) and
>   refuses to provide __stack_chk_fail_local:
>   https://www.openwall.com/lists/musl/2018/09/11/2

It's not that we refuse; it's that we can't, at least not without
gratuitously changing other things. libc.so can't be made a linker
script because then the real .so would have a different name and the
DT_NEEDED would thereby change. (No, libc.so can't use DT_SONAME to
control the name because then if you install /lib/ld-musl-$(ARCH).so.1
on a glibc-based system and run ldconfig, ldconfig will forcibly ln -s
ld-musl-$(ARCH).so.1 /lib/libc.so, which is A Bad Thing.)

There is a half-serious proposal to put it in crti.o which is always
linked too, but that seems like an ugly hack to me...

> This makes musl effectively not support ssp on i386 and probably powerpc.

It's working for all dists because we/they just make GCC pass
-lssp_nonshared via specs.

> Currently gcc's assumption is that musl supports ssp symbols
> from libc on all targets:
>
> https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/configure.ac;h=a7521ee99436a7c12159bdde0471dc66d3c4288e;hb=HEAD#l6079
> 
>   6088 case "$target" in
>   6089*-*-musl*)
>   6090  # All versions of musl provide stack protector
>   6091  gcc_cv_libc_provides_ssp=yes;;
> 
> Clearly that assumption is not correct as __stack_chk_fail_local
> is not provided by musl and linking fails.
> 
> This sounds like a expectation mismatch between gcc and musl
> of what it takes to implement an ssp interface.
> 
> What should we do to make it fixed long term and short term?
> 
> Long term:
> 
> Is there a vision of perfect end state agreed with gcc/glibc/musl
> folk so we could just implement it? If there is none let's try to
> form one.
> 
> My understanding of requirements for libc that exposes ssp support:
> - __stack_chk_fail is implemented as a default symbol
> - __stack_chk_fail_local is implemented as a local symbol to avoid PLT.
>   (Why is it important? To avoid use of potentially already broken stack?)

Because performance cost of -fstack-protector would go from 1-2% up to
5-10% on i386 and other archs where PLT contract requires a GOT
register, since loading the GOT register is expensive
(__x86.get_pc_thunk.* thunk itself is somewhat costly, and you throw
away one of only a small number of available registers, increasing
register pressure and hurting codegen).

> My understanding of possible perfect end state:
> 1. All libcs are required to somehow provide both __stack_chk_fail
>and __stack_chk_fail_local: be it linker script, crt*.o files or an extra
>libc_nonshared.a which gcc explicitly uses. Which one is best?
> 2. All libcs are required to provide only __stack_chk_fail and gcc always
>provides __stack_chk_local from libgcc.a, or from new libgcc_ssp.a.
>Evntually glibc drops it's __stack_chk_fail definition.
> 3. Your variant.
> 
> How do you gcc/glibc/musl folk see it? Once we decide I'll fi

Re: Git ChangeLog policy for GCC Testsuite inquiry

[Jeff Law]

On Sat, 2020-01-25 at 10:50 -0500, Nathan Sidwell wrote:
> On 1/24/20 4:36 PM, Jeff Law wrote:
> > On Fri, 2020-01-24 at 20:32 +0100, Eric Botcazou wrote:
> > > > I strongly prefer to move towards relying on the git log.
> > > 
> > > In my experience the output of git log is a total mess so cannot replace
> > > ChangeLogs.  But we can well decide to drop ChangeLog for the testsuite.
> > Well, glibc has moved to extracting them from git, building policies
> > and scripts around that.  I'm pretty sure other significant projecs are
> > also extracting their ChangeLogs from git.
> > 
> > We could do the same, selecting some magic date as the cutover point
> > after which future ChangeLogs are extracted from GIT.  In fact, that's
> > precisely what I'd like to see us do.
> 
> The GCC10 release date would seem a good point to do this.  That gives us 
> around 
> 3 months to figure the details (and get stakeholder buy-in)
Yup.  That would be what I'd recommend we shoot for.  As you say it
gives time to work on the details and for folks to start changing their
habits.

jeff

Re: Git push account

[Jeff Law]

On Sat, 2020-01-25 at 12:39 +, Feng Xue OS wrote:
> Which account should I use to push my local patch to git repo of gcc? 
> I have a sourceware account that works for svn, but now it doesn't for git.
> Actually both below commands were tried, but failed.
>   git push ssh://f...@sourceware.org/gcc/gcc.git ..., 
>   git push ssh://f...@gcc.gnu.org/gcc/gcc.git ...
It shouldn't matter.  Under the hood sourceware.org and gcc.gnu.org are
the same machine.

jeff

gcc-9-20200125 is now available

[gccadmin]

Snapshot gcc-9-20200125 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/9-20200125/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 9 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-9 
revision 7058d1744c663363b8de1e03a2ace8ecf3fa3144

You'll find:

 gcc-9-20200125.tar.xzComplete GCC

  SHA256=98f77bc5e862d5ee223589aa8f7b1301774533199e8a707b5ea73b09a2df1ab9
  SHA1=89c2a3f32407b103266ea5a84edef56ac2ad6517

Diffs from 9-20200118 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-9
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.