[Bug c/44975] Stack trashed by call inside inline asm
--- Comment #4 from ramiro dot polla at gmail dot com 2010-07-18 22:08 --- That won't work in this case. If I subtract anything from rsp inside the inline asm, the local variable relative to f will no longer be valid. Notice where gcc put it: 21: ff 54 24 f8 callq *-0x8(%rsp) Is there no way to tell gcc that either a call is being made inside the inline asm or that this function should not be considered a leaf function? If there isn't one yet, could such a feature request be acceptable? (like __attribute__((no_leaf_function)) or something) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44975
[Bug c/44975] New: Stack trashed by call inside inline asm
When there are no functions being called by the C code, gcc decides to use
negative offsets in the stack instead of sub'ing rsp. But if there's a call
inside an inline asm, it will trash the stack with a return pointer, and that
might lead to random code being run, for example:
$ cat main.c
void __attribute__((noinline)) dummy(void) {}
void __attribute__((noinline)) runtwice(void (**x)(void))
{
void (*f)(void) = x[0];
asm(movq $0x00, -16(%rsp)\n\t);
#ifdef ONE_IN_C
f();
#else
asm(call *%0\n\t::m(f));
#endif
asm(call *%0\n\t::m(f));
}
int main()
{
void (*f[])(void) = { dummy };
runtwice(f);
return 0;
}
$ gcc -O2 -g -o main-noc.o -c main.c
$ gcc -O2 -g -o main-c.o -c main.c -DONE_IN_C
$ gcc -o main-noc main-noc.o
$ gcc -o main-c main-c.o
$ ./main-noc
Segmentation fault
$ ./main-c
$
The disassembly of the runtwice function gives:
0010 runtwice: (no C functions being called)
10: 48 8b 07mov(%rdi),%rax
13: 48 89 44 24 f8 mov%rax,-0x8(%rsp)
18: 48 c7 44 24 f0 00 00movq $0x0,-0x10(%rsp)
1f: 00 00
21: ff 54 24 f8 callq *-0x8(%rsp)
25: ff 54 24 f8 callq *-0x8(%rsp)
29: c3 retq
0010 runtwice: (one C function being called)
10: 48 83 ec 18 sub$0x18,%rsp
14: 48 8b 07mov(%rdi),%rax
17: 48 89 44 24 08 mov%rax,0x8(%rsp)
1c: 48 c7 44 24 f0 00 00movq $0x0,-0x10(%rsp)
23: 00 00
25: ff d0 callq *%rax
27: ff 54 24 08 callq *0x8(%rsp)
2b: 48 83 c4 18 add$0x18,%rsp
2f: c3 retq
I put that asm(movq $0x00, -16(%rsp)\n\t); there to explicitly clear the next
pointer that would be called, but it could contain anything on a more complex
program.
I did not find in the documentation whether it is possible to hint the inline
asm block that a function is being called inside it.
--
Summary: Stack trashed by call inside inline asm
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ramiro dot polla at gmail dot com
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44975
[Bug c/44975] Stack trashed by call inside inline asm
--- Comment #2 from ramiro dot polla at gmail dot com 2010-07-18 05:14 --- Thanks. Is there anything that can be done in the code to say that is not a leaf function, or at least to tell gcc that a call is being made inside the inline asm? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44975
[Bug bootstrap/28756] `make install` is broken, doesn't install `gcc` when program_prefix == ${triplet}-
--- Comment #2 from ramiro dot polla at gmail dot com 2010-07-02 14:33 --- Still reproducible with 4.5.0. For example: ../gcc-4.5.0/configure --target=i686-pc-mingw32 --enable-languages=c --program-prefix=i686-pc-mingw32- --program-suffix=-4.5.0 --enable-version-specific-runtime-libs -- ramiro dot polla at gmail dot com changed: What|Removed |Added CC||ramiro dot polla at gmail ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28756
[Bug regression/40905] New: GCC creates invalid executable with auto-imported DLL and __attribute__((cold))
GCC creates invalid executable when an array from one DLL is accessed from
another DLL in a function with __attribute__((cold)).
--
$ cat dll1.c
int foo[2] = {0, 1};
$ cat dll2.c
extern int foo[2];
__attribute__((cold))
int bar(void)
{
return foo[1];
}
$ cat main.c
int bar(void);
int main()
{
bar();
return 0;
}
$ cat Makefile
CC=i686-mingw32-gcc-4.4.1
all:
$(CC) -shared -o dll1.dll dll1.c
$(CC) -shared -o dll2.dll dll2.c dll1.dll -O2
$(CC) -o main.exe main.c dll1.dll dll2.dll
$ make
i686-mingw32-gcc-4.4.1 -shared -o dll1.dll dll1.c
i686-mingw32-gcc-4.4.1 -shared -o dll2.dll dll2.c dll1.dll -O2
Info: resolving _foo by linking to __imp__foo (auto-import)
/opt/i686-mingw32/lib/gcc/i686-mingw32/4.4.1/../../../../i686-mingw32/bin/ld:
warning: auto-importing has been activated without --enable-auto-import
specified on the command line.
This should work unless it involves constant data structures referencing
symbols from auto-imported DLLs.
i686-mingw32-gcc-4.4.1 -o main.exe main.c dll1.dll dll2.dll
$ ./main.exe
err:module:attach_process_dlls dll2.dll failed to initialize, aborting
err:module:LdrInitializeThunk Main exe initialization for
LZ:\\home\\ramiro\\code\\smalls\\gcc_bug\\main.exe failed, status c005
--
This error message is from wine, but it also fails on Windows XP.
The auto-import warning seems to fit perfectly here but the same test doesn't
fail at -O1, or if __attribute__((cold)) is removed.
--
Summary: GCC creates invalid executable with auto-imported DLL
and __attribute__((cold))
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: regression
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ramiro dot polla at gmail dot com
GCC target triplet: i686-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40905
[Bug target/40905] GCC creates invalid executable with auto-imported DLL and __attribute__((cold))
--- Comment #2 from ramiro dot polla at gmail dot com 2009-07-30 03:43 --- I might be guessing wildly since I don't know that much about PE, but this is what more I've found: It crashes loading the dll in __pei386_runtime_relocator at address 65ec12a8: 65ec1290 __pei386_runtime_relocator: 65ec1290: 55 push %ebp 65ec1291: b9 28 40 ec 65 mov$0x65ec4028,%ecx 65ec1296: 89 e5 mov%esp,%ebp 65ec1298: eb 14 jmp65ec12ae __pei386_runtime_relocator+0x1e 65ec129a: 8d b6 00 00 00 00 lea0x0(%esi),%esi 65ec12a0: 8b 51 04mov0x4(%ecx),%edx 65ec12a3: 8b 01 mov(%ecx),%eax 65ec12a5: 83 c1 08add$0x8,%ecx 65ec12a8: 01 82 00 00 ec 65 add%eax,0x65ec(%edx) 65ec12ae: 81 f9 30 40 ec 65 cmp$0x65ec4030,%ecx 65ec12b4: 72 ea jb 65ec12a0 __pei386_runtime_relocator+0x10 65ec12b6: 5d pop%ebp 65ec12b7: c3 ret In the same testcase compiled without -O2, I get the sole entry of runtime_pseudo_reloc in __RUNTIME_PSEUDO_RELOC_LIST__ (the equivalent to 0x65ec4028) is: addend = 0x0004 target = 0x11d5 and the .text section is: 0 .text 0344 67701000 67701000 0400 2**4 CONTENTS, ALLOC, LOAD, CODE, DATA With -O2 it is: addend = 0x0004 target = 0x2005 0 .text 0334 65ec1000 65ec1000 0600 2**4 CONTENTS, ALLOC, LOAD, CODE, DATA 1 .text.unlikely 000c 65ec2000 65ec2000 0a00 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE Is it possible that it triggers the exception trying to write in text.unlikely which is READONLY? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40905
