Bug 59674 - On m68k and vax variables stack variables with > MAX_STACK_ALIGNMENT make ssp fail
Summary: On m68k and vax variables stack variables with > MAX_STACK_ALIGNMENT make ssp...
Status: RESOLVED DUPLICATE of bug 48690
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: unknown
: P5 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-01-04 04:14 UTC by Christos Zoulas
Modified: 2015-01-16 20:04 UTC (History)
3 users (show)

See Also:
Host:
Target: m68k-*-netbsd, vax-*-netbsd
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Christos Zoulas 2014-01-04 04:14:40 UTC
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)
Comment 1 Mikael Pettersson 2014-01-04 11:20:12 UTC
Works, as in generates OK looking code w/o issuing any diagnostics, on both m68k-linux and vax-linux for me.  A NetBSD issue?
Comment 2 Christos Zoulas 2014-01-04 16:16:09 UTC
On Jan 4, 11:20am, 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 #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?

Are you using a native compiler or a cross-compiler? We are using a cross
compiler from amd64.

christos
Comment 3 Mikael Pettersson 2014-01-04 17:22:50 UTC
I tested both targets with cross compilers from x86_64-linux.  I also tested natively on m68k-linux.
Comment 4 Christos Zoulas 2014-01-04 19:31:07 UTC
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
Comment 5 Mikael Pettersson 2014-01-04 20:42:03 UTC
(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.
Comment 6 Christos Zoulas 2014-01-04 21:20:57 UTC
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
Comment 7 Andreas Schwab 2014-01-04 21:49:06 UTC
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.
Comment 8 Martin Husemann 2014-01-23 17:11:59 UTC
(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.
Comment 9 Andreas Schwab 2014-01-24 21:37:49 UTC
x86 works around its weird ABI by dynamic stack realignment.  That's what needs to be implemented for your ABI as well.
Comment 10 Jeffrey A. Law 2015-01-16 18:56:47 UTC
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.
Comment 11 Jeffrey A. Law 2015-01-16 20:04:37 UTC
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 ***