[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Tinycc-devel] Re : Disabling memmove optimization
From: |
david . koch |
Subject: |
[Tinycc-devel] Re : Disabling memmove optimization |
Date: |
Tue, 26 Apr 2022 17:07:23 +0200 (CEST) |
What you are requesting when "return b" is indeed a memory move (copy)
operation.
Since your overriding the C language's memory operations, you have to provide
your own.
It should be named either "memmove" or "_memmove" provided at link time.
Look for :
" -nostdinc do not use standard system include paths\n"
" -nostdlib do not link with standard crt and libraries\n"
That might be your dope.
https://tinycc-devel.nongnu.narkive.com/9qKgFxHl/nostdlib-option-in-libtcc
https://www.reddit.com/r/kernel/comments/iv9aey/gcc_nostdlib_vs_nolibc/
http://cs107e.github.io/guides/gcc/
Regards.
----- Mail d'origine -----
De: Raul Hernandez <raul.hernandez@spaceface.dev>
À: tinycc-devel@nongnu.org
Envoyé: Tue, 26 Apr 2022 11:04:02 +0200 (CEST)
Objet: [Tinycc-devel] Disabling memmove optimization
Hi, list,
I’ve noticed that, in some cases, TCC will emit calls to standard library
functions such as memmove.
For example, the following snippet:
struct Big { void *a, *b, *c; };
struct Big some_function(struct Big b) {
return b;
}
… compiles to something like this (cleaned up for readability; the full
assembled code can be seen on Godbolt: https://godbolt.org/z/d4nh7oh63
<https://godbolt.org/z/d4nh7oh63>):
some_function:
push rbp
mov rbp, rsp
sub rsp, 0x10
(...)
lea rsi, [rbp+0x10]
mov rdi, QWORD PTR [rbp-0x10]
mov edx, 0x18
mov eax, 0x0
call memmove
leave
ret
I guess TCC does this as either an optimization (to take advantage of
vectorization in the implementation of memmove), or as a way of simplifying the
generated code.
My question is: is there any way of disabling this behavior? Ideally I’d wish
to be able to disable it for a single function, but I’d be happy with a
compiler flag when invoking TCC or a compile-time define when building it.
***
This probably sounds like the XY problem; the reason why I need to change that
behavior is that I’m trying to write a closure implementation for the V
programming language. It works similarly to the approach described in
https://nullprogram.com/blog/2017/01/08/
<https://nullprogram.com/blog/2017/01/08/>, but I’m trying to write it in pure
C for portability (so that it works with any calling convention and number of
parameters). The implementation works correctly when compiled with GCC and
clang, but sometimes fails under TCC because of the optimization I described.
Any function calls within the closure wrapper will become invalid after the
wrapper is copied somewhere else in memory, since the relative offset to that
function will be different and the CPU will jump to a garbage location instead.
Thank you,
Raul