for University we need to implement our own va_start and va_arg (without using libraries) for variable argument lists.
This isn't really a problem, but gcc and clang are giving us a hard time.
They are optimizing the code so that the parameter are passed through registers and not on the stack, which makes our task impossible.
I already tried to use optimization -O0 but even then they seem to pass them in registers.
Is there a way to disable that feature?
best wishes
Leo
Edit:
We are using 64-bit machines only
Edit2:
I found this site:
https://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_17.html
It describes macros which define if a parameter is passed on the stack or not.
Could I use these marcos somehow to tell gcc to pass all parameters on the stack?
I played around with them but sadly did not archive anything...
Related
GCC online doc - 3.10 Options That Control Optimization affirm that -fomit-frame-pointer gcc option can make debbuging impossible.
-fomit-frame-pointer
Don't keep the frame pointer in a register for functions that don't need one. This avoids the instructions to save, set up and restore frame pointers; it also makes an extra register available in many functions. It also makes debugging impossible on some machines.
I understand why local variables are harder to locate and stack traces are much harder to reconstruct without a frame pointer to help out.
But, In what circumstances is it make debugging impossible?
It may be impossible in the sense that existing tools for these platforms (which are often provided by platform vendor, not GNU) expect frame pointer to be present for successful unwinding. One could theoretically modify them to be more intelligent but in practice this is not possible.
I want to investigate a way for my other question (gcc: Strip unused functions) by building the latest gcc 6.3.0.
There are some options from https://gcc.gnu.org/install/configure.html and https://gcc.gnu.org/onlinedocs/libstdc++/manual/configure.html that I would like to try, but don't understand what they meant.
Specifically, these are the flags I want to try:
--disable-libstdcxx-verbose: I rarely use exceptions so I am not very familiar with how it works. I have never seen the "verbose messages" it mentioned before.
--enable-linker-build-id and --enable-gnu-unique-object: Simply don't understand what the explanations are trying to say. What are the benefits exactly?
--enable-cxx-flags="-ffunction-sections -fstrict-aliasing -fno-exceptions": If I use -fno-exceptions in libstdc++, doesn't that means I get no exceptions if I use libstdc++? -ffunction-sections is used, but where to put -Wl,-gc-sections?
Although I always use --enable-lto, but with ld.bfd, it seems to be quite useless compared to the famous gold linker.
If you have more flags you think I should try, please let me know!
--disable-libstdcxx-verbose: I rarely use exceptions
so I am not very familiar with how it works. I have never seen the
"verbose messages" it mentioned before.
+1, you normally don't run into errors which trigger these friendly error messages you can avoid paying for them.
--enable-linker-build-id and --enable-gnu-unique-object:
Simply don't understand what the explanations are trying to say.
What are the benefits exactly?
There are none.
Unique objects is a badly designed feature that prevents shared libraries which contain references to globally used objects (usually vtables) from unloading on dlclose. AFAIR it's enabled by default (as it's needed to simulate C++ semantics in shared libs environment).
Build id is needed to support separate debuginfo.
--enable-cxx-flags="-ffunction-sections -fstrict-aliasing -fno-exceptions":
You won't benefit from -fstrict-aliasing as it's enabled at -O2 and higher by default.
-ffunction-sections is used, but where to put -Wl,-gc-sections?
To --enable-cxx-flags as well (note that it wants double-dash i.e. -Wl,--gc-sections).
Although I always use --enable-lto, but with ld.bfd,
it seems to be quite useless compared to the famous gold linker.
This flags simply enables LTO support in GCC (it's actually equivalent to adding lto to --enable-languages). It won't cause any difference unless you enable -flto in CXXFLAGS as well. Keep in mind that LTO will normally increase executable size (as compiler will have more opportunities for inlining).
If you have more flags you think I should try, please let me know!
Speaking of size reduction, I'd say -ffunction-sections is your best bet (be sure to verify that configure machinery passes all options correctly and libstdc++.a indeed has one section per function). You could also add -fdata-sections.
I've recently played around with the target_clones attribute available from gcc 6.1 and onward. It's quite nifty, but, for now, it requires a somewhat clumsy approach; every function that one wants multi-versioned has to have an attribute declared manually. This is less than optimal because:
It puts compiler-specific stuff in the code.
It requires the developer to identify which functions should receive this treatment.
Let's take the example where I want to compile some code that will take advantage of AVX2 instructions, where available. -fopt-info-vect will tell me which functions were vectorized, if I build with -mavx2, so the compiler already knows this. Is there a way to, globally, tell the compiler: "If you find a function which you feel could be optimized with AVX2, make multiple versions, with and without AVX2, of that function."? And if not, can we have one, please?
I'm trying to compile code on GCC that uses OpenACC to offload to an NVIDIA GPU but I haven't been able to find a similar compiler option to the one mentioned above. Is there a way to tell GCC to be more verbose on all operations related to offloading?
Unfortunately, GCC does not yet provide a user-friendly interface to such information (it's on the long TODO list...).
What you currently have to do is look at the dump files produced by -fdump-tree-[...] for the several compiler passes that are involved, and gather information that way, which requires understanding of GCC internals. Clearly not quite ideal :-/ -- and patches welcome probably is not the answer you've been hoping for.
Typically, for a compiler it is rather trivial to produce diagnostic messages for wrong syntax in source code ("expected [...] before/after/instead of [...]"), but what you're looking for is diagnostic messages for failed optimizations, and similar, which is much harder to produce in a form that's actually useful for a user, and so far we (that is, the GCC developers) have not been able to spend the required amount of time on this.
I am currently developing a library for QNX (x86) using GCC, and I want to make some symbols which are used exclusively in the library and are invisible to other modules, notably to the code which uses the library.
This works already, but, while doing the research how to achieve it, I have found a very worrying passage in GCC's documentation (see http://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/Code-Gen-Options.html#Code-Gen-Options, explanation for flag -fvisibility):
Despite the nomenclature, default always means public; i.e., available
to be linked against from outside the shared object. protected and
internal are pretty useless in real-world usage so the only other
commonly used option is hidden. The default if -fvisibility isn't
specified is default, i.e., make every symbol public—this causes the
same behavior as previous versions of GCC.
I am very interested in how visibility "internal" is pretty useless in real-world-usage. From what I have understood from another passage from GCC's documentation (http://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/Function-Attributes.html#Function-Attributes, explanation of the visibility attribute), visibility "internal" is even stronger (more useful for me) than visibility "hidden":
Internal visibility is like hidden visibility, but with additional
processor specific semantics. Unless otherwise specified by the psABI,
GCC defines internal visibility to mean that a function is never
called from another module. Compare this with hidden functions which,
while they cannot be referenced directly by other modules, can be
referenced indirectly via function pointers. By indicating that a
function cannot be called from outside the module, GCC may for
instance omit the load of a PIC register since it is known that the
calling function loaded the correct value.
Could anybody explain in depth?
If you just want to hide your internal symbols, just use -fvisibility=hidden. It does exactly what you want.
The internal flag goes much further than the hidden flag. It tells the compiler that ABI compatibility isn't important, since nobody outside the module will ever use the function. If some outside code does manage to call the function, it will probably crash.
Unfortunately, there are plenty of ways to accidentally expose internal functions to the outside world, including function pointers and C++ virtual methods. Plenty of libraries use callbacks to signal events, for example. If your program uses one of these libraries, you must never use an internal function as the callback. If you do, the compiler and linker won't notice anything wrong, and your program will have subtle, hard-to-debug crash bugs.
Even if your program doesn't use function pointers now, it might start using them years down the road when everyone (including you) has forgotten about this restriction. Sacrificing safety for tiny performance gains is usually a bad idea, so internal visibility is not a recommended project-wide default.
The internal visibility is more useful if you have some heavily-used code that you are trying to optimize. You can mark those few specific functions with __attribute__ ((visibility ("internal"))), which tells the compiler that speed is more important than compatibility. You should also leave a comment for yourself, so you remember to never take a pointer to these functions.
I cannot provide in-depth answer, but I think that "internal" might be unpractical because it is processor dependent. You might get expected behaviour on some systems, but on others you get only "hidden".