public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* Still problems with alloca and frame layout on w64 targets
@ 2008-05-27 14:59 Kai Tietz
  2008-05-27 15:02 ` Kai Tietz
  0 siblings, 1 reply; 2+ messages in thread
From: Kai Tietz @ 2008-05-27 14:59 UTC (permalink / raw)
  To: gcc; +Cc: Uros Bizjak, Jan Hubicka, ktietz70

[-- Attachment #1: Type: text/plain, Size: 661 bytes --]

Hi,

this small c program produces wrong code on x86_64-pc-mingw32. The problem 
here is the call abi w64. For w64 call abi, the last reserved 32 bytes on 
stack are use for vaarg functions to save the incoming arguments from 
register. This works fine as long as there is no alloca call within the 
function calling a vaarg method. The alloca reserves just the stack, but 
does not move the stack clobber region. So by a vaarg call the last 
reserved stack is clobbered.

How and where can I solve this problem?

Thanks in advance,
Kai



|  (\_/)  This is Bunny. Copy and paste Bunny
| (='.'=) into your signature to help him gain
| (")_(") world domination.

[-- Attachment #2: test.c --]
[-- Type: application/octet-stream, Size: 578 bytes --]

#include <stdio.h>
#include <stdlib.h>
#include <memory.h>
#include <stdarg.h>

void do_zero (int argc, ...)
{
  va_list argp;
  char *c;
  va_start(argp, argc);
  while ((c=va_arg(argp,char *))!=NULL)
    memset(c,0,32);
  va_end (argp);
}

void do_print (const char *fmt, const char *h,int s)
{
  int i;
  for (i=0;h[i]==0 && i<s;i++);
  if (i!=s) abort ();
}

int main (int argc,char **argv)
{
  char *a,*b;
  a = (char *) alloca (argc * 32);
  do_zero (0,a,b,NULL);
  b = (char *) alloca (argc * 32);
  do_print ("a",a,argc * 32);
  do_print ("a",b,argc * 32);
  return 0;
}

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: Still problems with alloca and frame layout on w64 targets
  2008-05-27 14:59 Still problems with alloca and frame layout on w64 targets Kai Tietz
@ 2008-05-27 15:02 ` Kai Tietz
  0 siblings, 0 replies; 2+ messages in thread
From: Kai Tietz @ 2008-05-27 15:02 UTC (permalink / raw)
  To: gcc; +Cc: Jan Hubicka, ktietz70, Uros Bizjak

[-- Attachment #1: Type: text/plain, Size: 719 bytes --]

> Hi,
> 
> this small c program produces wrong code on x86_64-pc-mingw32. The 
problem 
> here is the call abi w64. For w64 call abi, the last reserved 32 bytes 
on 
> stack are use for vaarg functions to save the incoming arguments from 
> register. This works fine as long as there is no alloca call within the 
> function calling a vaarg method. The alloca reserves just the stack, but 

> does not move the stack clobber region. So by a vaarg call the last 
> reserved stack is clobbered.
> 
> How and where can I solve this problem?

Sorry I attached wrong testcase

Thanks in advance,
Kai



|  (\_/)  This is Bunny. Copy and paste Bunny
| (='.'=) into your signature to help him gain
| (")_(") world domination.

[-- Attachment #2: test.c --]
[-- Type: application/octet-stream, Size: 616 bytes --]

#include <stdio.h>
#include <stdlib.h>
#include <memory.h>
#include <stdarg.h>

void do_zero (int argc, ...)
{
  va_list argp;
  char *c;
  va_start(argp, argc);
  while ((c=va_arg(argp,char *))!=NULL)
    memset(c,0,argc);
  va_end (argp);
}

void do_print (const char *fmt, const char *h,int s)
{
  int i;
  for (i=0;h[i]==0 && i<s;i++);
  if (i!=s) abort ();
}

int main (int argc,char **argv)
{
  char *a,*b;
  a = (char *) alloca (argc * 32);
  do_zero (argc * 32,a,NULL);
  b = (char *) alloca (argc * 32);
  do_zero (argc * 32,b,NULL);
  do_print ("a",a,argc * 32);
  do_print ("a",b,argc * 32);
  return 0;
}

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2008-05-27 15:02 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-05-27 14:59 Still problems with alloca and frame layout on w64 targets Kai Tietz
2008-05-27 15:02 ` Kai Tietz

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).