This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Do we want to add -fsanitize=function?


On 1/14/20 12:54 PM, Jakub Jelinek wrote:
On Tue, Jan 14, 2020 at 12:36:11PM +0100, Martin Liška wrote:
The missing sanitizer reports about violations of function signatures
for indirect calls, like:

$ cat sanitize-function.cpp
#include <inttypes.h>

void f() {}
void (*fnpointer) (int);

void save () {
   fnpointer = reinterpret_cast<void (*)(int)>(reinterpret_cast<uintptr_t>(f));
}

int main(void) {
   save ();
   fnpointer (32);
}

_Z4savev:                               # @_Z4savev
	.cfi_startproc
	.long	846595819               # 0x327606eb
	.long	.L__unnamed_2-_Z4savev
# %bb.0:                                # %entry
	...
seems to be what they emit on x86_64.  Now, wonder what they do on other
targets

Other targets are not supported :P

, and how does it play with all the other options that add stuff
to the start of functions, e.g. -fcf-protection=full (where it needs to
really start with endbr64 instruction)

Using the options one will get:

_Z4savev:                               # @_Z4savev
	.cfi_startproc
	.long	846595819               # 0x327606eb
	.long	.L__unnamed_2-_Z4savev
# %bb.0:
	endbr64

So endbr64 is placed after the RTTI record.

, or the various options for
patcheable function entries, -mfentry, profiling and the like.

These work similarly, then follow the RTTI record:

_Z4savev:                               # @_Z4savev
	.cfi_startproc
	.long	846595819               # 0x327606eb
	.long	.L__unnamed_2-_Z4savev
# %bb.0:
	callq	__fentry__

Martin


	Jakub



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]