I am injecting some control flow monitoring codes to a program. I get an assembly code generated by GCC C compiler (flag -S). Then I add some monitoring codes in assembly before every indirect branches within the application. Those monitoring codes needs to use some registers and therefore, for every branch I inject the code I have to push and pop the registers I use in order to save the previously written value and return them after.
However since the performance is an issue, I was wondering if I can avoid the push pops when I convert the C code to assembly code and tell the GCC to generate assembly code without using one or two specific register. Therefore, I can avoid using push pops for every indirect branch to save the existing values in the register.
Is there any way to do that?
See the -ffixed-reg option.
Note that if the register in question is required to be used for passing arguments, etc, this won't work (indeed, it appears that in that case, gcc will silently use it anyway).
Related
I'm currently developing a C code for a RISC-V SoC that I'm compiling using GCC. I have a foo(a,b) function, and I need to provide its address to the hardware through a customed CSR (Control and Status Register) using CSRRW. As of now, I was defining a macro, compiling/linking the program, changing the value of the macro according to the generated firmware, compiling/linking again and checking that the address didn't change. Nevertheless, I'd like to have a more generic approach, hence the use of pointers.
I tried to simply associate the function base address to a variable (addr = foo), which is working most of the time. However, after compiling and linking the code with GCC (and -O3 optimization), I've noticed that 2 versions of the function were created:
<foo>
<foo.constprop.0>
The pointer I get in the code is referring to the first one, however, I would also need a variable to point to the second one. Is there a generic way to deal with this?
EDIT:
As Nate Eldredge suggested, I created a function foo_const() calling foo(0,0). What happens is that GCC is creating <foo_const> with a jump instruction only. So a pointer to foo_const would not fix the issue.
I also tried to copy and adapt the content of foo(a,b) in foo_const() by replacing the arguments with constants. This work as the called function is directly the one I created and not the 'constprop' anymore. However, it doesn't really reply to my question as it is a workaround not to point to 'constprop' instead of a way to point to it, and also there is a negative impact on performances.
I'm currently writing some bare-metal code for, among others, armv6-m using (arm-none-eabi-)gcc as compiler.
When implementing the exception-handlers I stumbled upon __attribute__((interrupt("type"))) (manual) telling gcc to generate a function that preserves all registers (apart from banked ones).
The problem is that this generated function always (more or less) returns execution to wherever it was supposed to be before the interrupt. While desirable for regular interrupts, this is exactly not what you want when dealing with e.g. undefined instruction exceptions, as you then spin on said undefined instruction. While I can find a macro that is supposed to get me the return address, I can't find one to set or modify it. This seems like an obvious thing to be included with e.g. the type "undef" as returning to the old pc is basically guaranteed to just retrigger the exception.
TLDR: Is there some way to modify the return address of an interrupt handler or a general c function in gcc?
And please don't tell me to just write an assembly wrapper, I know that would fix it & already have a few of those, but if this work is already done by gcc I'd prefer to not worry about register clobbering and optimization myself.
Is there anyway to mark a function as inline, but still have at available to call at the debugger? All of my functions I would like to call are marked as static inline, because we are only allowed to expose certain functions in our file. I'm using gcc.
-ginline-points could help:
Generate extended debug information for inlined functions. Location view tracking markers are inserted at inlined entry points, so that address and view numbers can be computed and output in debug information. This can be enabled independently of location views, in which case the view numbers won’t be output, but it can only be enabled along with statement frontiers, and it is only enabled by default if location views are enabled.
In-lined functions have no return instruction, so even if you had the address of the start of the in-lined function, calling it from the debugger would execute the code that follows the in-lining, of which it would almost certainly not have a suitable stack frame.
It is not usual, and certainly not easy do debug optimised code in any case. Normally one would simply switch optimisation off for debugging - in GCC at least, the inline keyword is ignored at -O0.
This is one of the issues when optimizing the code. You need to lower the optimizations a little bit (Usual recommendations in CMake for instance is to use -O2 instead of -O3) and add -fno-omit-frame-pointer to the command line (it will make code slower, as it allocates a register to keep track on the stack frame pointer during function calls).
On compilers like ICC, you can have even more debug info by using -debug all.
I'm dealing with some code that's getting 70-80% slower when compiled as PIC (position independent code), and looking for ways to alleviate the problem. A big part of the problem is that gcc insists on inserting the following in every single function:
call __i686.get_pc_thunk.bx
addl $_GLOBAL_OFFSET_TABLE_,%ebx
even if that ends up being 20% of the content of the function. Now, ebx is a call-preserved register, and every function in the relevant translation unit (source file) is loading it with the address of the GOT, and it's easily detectable that the static functions cannot be called from outside the translation unit (their addresses are never taken). So why can't gcc just load ebx once at the beginning of the big external-linkage functions, and generate the static-linkage functions so that they assume ebx has already been loaded with the address of the GOT? Is there any optimization flag I can use to force gcc to make this obvious and massive optimization, short of turning the inline limits up sky-high so everything gets inlined into the external functions?
There is probably no generic cure for this, but you could try to play around with inlining options. I'd guess that static functions in a compilation unit don't have too many callers, so the overhead in code replication wouldn't be too bad.
The easiest way to force such things with gcc would be to set an attribute((always_inline)). You could play around with a gcc dependent macro to ensure portability.
If you don't want to modify the code (but static inline would be good anyhow) you could use the -finline-limit option to fine tune that.
Not really a solution, but: if the functions in question do not reference file-scope variables, you could put them all together in a single translation unit and compile it without -fPIC flag. Then you link them together with other files in the final SO as usual.
I'm trying to test a rather threading-sensitive area in my program and was wondering if there's a way to force gcc to insert a call after every instruction it emits so that I can manually yield to a different thread?
Thanks,
Robert
No, GCC does not has such an option.
However, you may be able hack together a script that does that job. You can compile your code to assembler using the -S option. Compiler generated assembler is relative easy to parse.
Don't forget to save the flags and all registers inside your debugging code though.