[Bug c/59674] New: On m68k and vax variables stack variables with > MAX_STACK_ALIGNMENT make ssp fail

[Bug c/59674] New: On m68k and vax variables stack variables with > MAX_STACK_ALIGNMENT make ssp fail

[christos at zoulas dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59674

            Bug ID: 59674
           Summary: On m68k and vax variables stack variables with >
                    MAX_STACK_ALIGNMENT make ssp fail
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: christos at zoulas dot com

Thie simple example:

struct foo {
        const char *place;
        long long time;
};

extern int goo(struct foo *);
int foo(void);

int foo(void) {
        struct foo f;
        f.time = 1;
        f.place = "foo";
        return goo(&f);
}

When compiled, produces:

/usr/obj/x86_64/tools/bin/m68k--netbsdelf-gcc -Os -fstack-protector
-Wstack-protector --param ssp-buffer-size=1 -c foo.c
foo.c: In function 'foo':
foo.c:9:5: warning: stack protector not protecting local variables: variable
length buffer [-Wstack-protector]

There are no variable length buffers on the stack. The problem is that we end
up calling in cfgexpand.c:

      /* If there were any, allocate space.  */
      if (large_size > 0)
        large_base = allocate_dynamic_stack_space (GEN_INT (large_size), 0,
                                                   large_align, true);

Changing long long to int, works just fine. It is a serious limitation not to
be able to protect stacks that contain long long or double. Here's the gcc
version:

$ /usr/obj/x86_64/tools/bin/m68k--netbsdelf-gcc -v
Using built-in specs.
COLLECT_GCC=/usr/obj/x86_64/tools/bin/m68k--netbsdelf-gcc
COLLECT_LTO_WRAPPER=/usr/obj/x86_64/tools/libexec/gcc/m68k--netbsdelf/4.8.3/lto-wrapper
Target: m68k--netbsdelf
Configured with:
/p/netbsd/cvsroot/src/tools/gcc/../../external/gpl3/gcc/dist/configure
--target=m68k--netbsdelf --enable-long-long --enable-threads
--with-bugurl=http://www.NetBSD.org/Misc/send-pr.html --with-pkgversion='NetBSD
nb1 20120916' --with-system-zlib --enable-__cxa_atexit
--with-sysroot=/usr/obj/sun3/release --with-mpc=/usr/obj/x86_64/tools
--with-mpfr=/usr/obj/x86_64/tools --with-gmp=/usr/obj/x86_64/tools
--disable-nls --disable-multilib --program-transform-name=s,^,m68k--netbsdelf-,
--enable-languages='c c++ objc' --prefix=/usr/obj/x86_64/tools
Thread model: posix
gcc version 4.8.3 20131213 (prerelease) (NetBSD nb1 20120916)

[Bug c/59674] On m68k and vax variables stack variables with > MAX_STACK_ALIGNMENT make ssp fail

[mikpelinux at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59674

--- Comment #1 from Mikael Pettersson <mikpelinux at gmail dot com> ---
Works, as in generates OK looking code w/o issuing any diagnostics, on both
m68k-linux and vax-linux for me.  A NetBSD issue?

[Bug c/59674] On m68k and vax variables stack variables with > MAX_STACK_ALIGNMENT make ssp fail

[mikpelinux at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59674

--- Comment #3 from Mikael Pettersson <mikpelinux at gmail dot com> ---
I tested both targets with cross compilers from x86_64-linux.  I also tested
natively on m68k-linux.

[Bug c/59674] On m68k and vax variables stack variables with > MAX_STACK_ALIGNMENT make ssp fail

[christos at zoulas dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59674

--- Comment #4 from Christos Zoulas <christos at zoulas dot com> ---
On Jan 4,  5:22pm, gcc-bugzilla@gcc.gnu.org ("mikpelinux at gmail dot com")
wrote:
-- Subject: [Bug c/59674] On m68k and vax variables stack variables with > MA

| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59674
| 
| --- Comment #3 from Mikael Pettersson <mikpelinux at gmail dot com> ---
| I tested both targets with cross compilers from x86_64-linux.  I also tested
| natively on m68k-linux.

My guess is that m68k-linux is not using the SVR4 ABI, i.e. it does not
require long long and double to be aligned on a doubleword boundary.

>From the comment in netbsd-elf.h:

/* No data type wants to be aligned rounder than this.
   For m68k/SVR4, some types (doubles for example) are aligned on 8 byte
   boundaries */

#undef BIGGEST_ALIGNMENT
#define BIGGEST_ALIGNMENT 64    

christos

[Bug c/59674] On m68k and vax variables stack variables with > MAX_STACK_ALIGNMENT make ssp fail

[mikpelinux at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59674

--- Comment #5 from Mikael Pettersson <mikpelinux at gmail dot com> ---
(In reply to Christos Zoulas from comment #4)
> My guess is that m68k-linux is not using the SVR4 ABI, i.e. it does not
> require long long and double to be aligned on a doubleword boundary.

That is correct, m68k-linux has looser alignment rules than most other archs. 
Which is why I also tested vax-linux, hoping that its ABI would be more in line
with other VAX targets.

[Bug c/59674] On m68k and vax variables stack variables with > MAX_STACK_ALIGNMENT make ssp fail

[christos at zoulas dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59674

--- Comment #6 from Christos Zoulas <christos at zoulas dot com> ---
On Jan 4,  8:42pm, gcc-bugzilla@gcc.gnu.org ("mikpelinux at gmail dot com")
wrote:
-- Subject: [Bug c/59674] On m68k and vax variables stack variables with > MA

| That is correct, m68k-linux has looser alignment rules than most other archs. 
| Which is why I also tested vax-linux, hoping that its ABI would be more in
line
| with other VAX targets.

We have the same problem with sh3 also. I think that the VAX issue is
a bit different. I will test and provide more details for both platforms.

christos

[Bug c/59674] On m68k and vax variables stack variables with > MAX_STACK_ALIGNMENT make ssp fail

[schwab@linux-m68k.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59674

--- Comment #7 from Andreas Schwab <schwab@linux-m68k.org> ---
If you have fundamental types with stricter alignment requirements than
provided by STACK_BOUNDARY your ABI has a problem, and this SSP failure is just
one symptom.

[Bug c/59674] On m68k and vax variables stack variables with > MAX_STACK_ALIGNMENT make ssp fail

[martin at netbsd dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59674

Martin Husemann <martin at netbsd dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |martin at netbsd dot org

--- Comment #8 from Martin Husemann <martin at netbsd dot org> ---
(In reply to Andreas Schwab from comment #7)
> If you have fundamental types with stricter alignment requirements than
> provided by STACK_BOUNDARY your ABI has a problem, and this SSP failure is
> just one symptom.

Why is that a fundamental problem? It is not that different to i386 and data
used for MMX/SSE instructions - "not nice", but the compiler should be able to
cope.

[Bug target/59674] On m68k and vax variables stack variables with > MAX_STACK_ALIGNMENT make ssp fail

[schwab@linux-m68k.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59674

--- Comment #9 from Andreas Schwab <schwab@linux-m68k.org> ---
x86 works around its weird ABI by dynamic stack realignment.  That's what needs
to be implemented for your ABI as well.

[Bug target/59674] On m68k and vax variables stack variables with > MAX_STACK_ALIGNMENT make ssp fail

[law at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59674

Jeffrey A. Law <law at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P5
                 CC|                            |law at redhat dot com

--- Comment #10 from Jeffrey A. Law <law at redhat dot com> ---
As Andreas stated, having an ABI where the alignment of fundamental data types
is larger than the alignment of the stack will not work without significant
development.

Basically nothing guarantees that you stack is aligned enough to allow you to
then align those fundamental types on the stack.

To get the stack aligned properly you have to dynamically realigned the stack
at function entry, much like what's done for x86.

Without the dynamic stack alignment support, I would call the ABI used by
m68k-netbsd fundamentally broken.  Sigh.

Downgrading to P5.   m68k dynamic stack realignment isn't going to be a
priority.

[Bug target/59674] On m68k and vax variables stack variables with > MAX_STACK_ALIGNMENT make ssp fail

[law at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59674

Jeffrey A. Law <law at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |DUPLICATE

--- Comment #11 from Jeffrey A. Law <law at redhat dot com> ---
Going to make 48690 the canonical BZ for problems with the netbsd alignment
issues.

*** This bug has been marked as a duplicate of bug 48690 ***