gcc/ld: Allow Code Placement And Removal of Unused Functions - gcc

I am trying to allow specifying the location of particular symbols in my output binary without giving up the garbage collection feature of ld. For example: if I have in MyInclude.h
#ifndef MY_INCLUDE_H_
#define MY_INCLUDE_H_
void CalledFunc(void);
void UncalledFunc(void);
#endif
and a main program:
#include "MyInclude.h"
int main(void)
{
CalledFunc();
return 0;
}
compiling with gcc with ffunction-sections -fdata-sections and linking with --gc-sections shows in the map file that .text.UncalledFunc has been removed.
I now have a need where I have to place certain functions in different sections. In this example if UncalledFunc() did happen to be called, I want it to be in a special section. I have a linker parameter file that looks something like:
MEMORY
{
FLASH (rx) : ORIGIN = 0x10000000, LENGTH = 512K
}
SECTIONS
{
.text.myregion ORIGIN(FLASH):
{
*(.text.myregion)
*(.text.myregion*)
} >FLASH
ASSERT ( . <= 0x10010000, "Too much stuff in myregion!")
.text :
{
*(.text)
*(.text*)
} >FLASH
}
And UncalledFunc() and CalledFunc() defined as:
void CalledFunc(void) __attribute__ ((section (".text.myregion")))
{
/* ... */
}
void UncalledFunc(void) __attribute__ ((section (".text.myregion")))
{
/* ... */
}
In this case, it seems the function attribute overrides the per function section parameter sent to GCC. As such since both functions are in the same input section, they both appear in the output image. Is there a way to tell the linker to place UncalledFunc() in .text.myregion if it is called but still remove it if it is not? As shown above, myregion has limited space and it would optimal to not place anything there that wasn't necessary.

The compiler is just doing what it's told; you asked it to put that function in that section, so what else should it do?
The linker then sees all the functions in one section, and so garbage collection is not very helpful.
I've not tried this, but I would imagine that simply assigning different manual names to each function will solve the problem:
void CalledFunc(void) __attribute__ ((section (".text.myregion.CalledFunc")))
{
/* ... */
}
void UncalledFunc(void) __attribute__ ((section (".text.myregion.UncalledFunc")))
{
/* ... */
}
However, if that's a lot of typing (or if you use a macro to apply the attribute), then it might be better like this:
#define STRINGIFY(S) #S
#define TOSTRING(S) STRINGIFY(S)
#define NAME __FILE__ "." TOSTRING(__LINE__)
void CalledFunc(void) __attribute__ ((section (".text.myregion." NAME)))
{
/* ... */
}
That way you can do it with search-and-replace and still have each function have a unique section name. (It is necessary to use the macro because __LINE__ is an integer value, but we need a string here, and the # "stringify" operator is only available inside macros. The apparently pointless levels of indirection cause __LINE__ to be evaluated into the actual line number.)
It might be that the __FUNCTION__ macro works, but I'm not confident given that this is outside the function body.

If you use link time optimization, compiler should be able to remove unused functions, even if you put all of them into common section.
So keep modules (let's say include.c include.h test.c), but build like this:
gcc -c -Os -flto include.c -o include.o
gcc -c -Os -flto test.c -o test.o
gcc -flto -Os test.o include.o -o test
This will probably (depends on actual code) inline used function and remove unused one (unless you use attribute noinline.

Related

Weird C library linkage issues on Mac - Segmentation Fault

I have a strange segmentation fault that doesn't exist when everything is in 1 .c file, but does exist when I put part of the code in a dynamically linked library and link it to a test file. The complete code for the working 1 .c file code is at the bottom, the complete code for the error system with 2 .c and 1 .h file come first.
Here is the error system:
example.h:
#include <stdio.h>
#include <stdlib.h>
typedef struct MYARRAY {
int len;
void* items[];
} MYARRAY;
MYARRAY *collection;
void
mypush(void* p);
example.c:
#include "example.h"
void
mypush(void* p) {
printf("Here %lu\n", sizeof collection);
puts("FOO");
int len = collection->len++;
puts("BAR");
collection->items[len] = p;
}
example2.c:
This is essentially a test file:
#include "example.h"
void
test_print() {
puts("Here1");
mypush("foo");
puts("Here2");
}
int
main() {
collection = malloc(sizeof *collection + (sizeof collection->items[0] * 1000));
collection->len = 0;
puts("Start");
test_print();
puts("Done");
return 0;
}
Makefile:
I link example to example2 here, and run:
example:
#clang -I . -dynamiclib \
-undefined dynamic_lookup \
-o example.dylib example.c
#clang example2.c example.dylib -o example2.o
#./example2.o
.PHONY: example
The output is:
$ make example
Start
Here1
Here 8
FOO
make: *** [example] Segmentation fault: 11
But it should show the full output of:
$ make example
Start
Here1
Here 8
FOO
BAR
Here2
Done
The weird thing is everything works if it is this system:
example.c:
#include <stdio.h>
#include <stdlib.h>
typedef struct MYARRAY {
int len;
void* items[];
} MYARRAY;
MYARRAY *collection;
void
mypush(void* p) {
printf("Here %lu\n", sizeof collection);
puts("FOO");
int len = collection->len++;
puts("BAR");
collection->items[len] = p;
}
void
test_print() {
puts("Here1");
mypush("foo");
puts("Here");
}
int
main() {
collection = malloc(sizeof *collection + (sizeof collection->items[0] * 1000));
collection->len = 0;
puts("ASF");
test_print();
return 0;
}
Makefile:
example:
#clang -o example example.c
#./example
.PHONY: example
Wondering why it's creating a segmentation fault when it is linked like this, and what I am doing wrong.
I have checked otool and with DYLD_PRINT_LIBRARIES=YES and it shows it is importing the dynamically linked libraries, but for some reason it's segmentation faulting when linked but works fine when it isn't linked.
Your problem is this, in example.h:
MYARRAY *collection;
Since both main.c and example.c include this file, you end up defining collection twice, which results in undefined behavior. You need to make sure you define each object only once. The details are relatively unimportant since anything can happen with undefined behavior, but what's probably happening is that main.c is allocating memory for one object, but the one example.c is using is still NULL. As mentioned in the comments, since you define collection in main.c your linker is able to build the executable without needing to look for that symbol in the dynamic library, so you don't get a link time warning about it being defined there too, and obviously there'd be no cause for a warning at the time you compile the library.
It works for you when you put everything in one file because obviously then you're not defining anything twice, anymore. The error itself is nothing to do with the fact you're using a dynamic library, although that may have made it harder to detect.
It would be better to define this in example.c and provide a constructor function, there's no need for main() to be able to access it directly. But if you must do this, then define it in example.c and just declare an extern identifier in the header file to tell main.c that the object is defined somewhere else.

Does MSP430 GCC support newer C++ standards? (like 11, 14, 17)

I'm writing some code that would greatly benefit from the concise syntax of lambdas, which were introduced with C++ 11. Is this supported by the compiler?
How do I specify the compiler flags when compiling using Energia or embedXcode?
As of February 2018, up to C++14 is supported with some limitations:
http://processors.wiki.ti.com/index.php/C%2B%2B_Support_in_TI_Compilers
There isn't much about this topic on the TI site, or, at least, I don't know enough C++ to give you a detailed and precise response.
The implementation of the embedded ABI is described in this document that is mainly a derivation of the Itanium C++ ABI. It explains nothing about the implementation of lambdas nor the auto, keyword (or probably I'm not able to derive this information from the documentation).
Thus I decided to directly test in Energia. Apparently the g++ version is 4.6.3, thus it should support both.
And in fact (from a compilation point of view, I don't have my MSP here to test the code) it can compile something like:
// In template.hpp
#ifndef TEMPLATE_HPP_
#define TEMPLATE_HPP_
template<class T>
T func(T a) {
auto c = [&](int n) { return n + a; };
return c(0);
}
#endif /* TEMPLATE_HPP_ */
// in the sketch main
#include "template.hpp"
void setup() { int b = func<int>(0); }
void loop() { }
(the template works only if in an header, in the main sketch raises an error). To compile this sketch I had to modify one internal file of the editor. The maximum supported standard seems to be -std=c++0x, and the compilation flags are in the file:
$ENERGIA_ROOT/hardware/energia/msp430/platform.txt
in my setup the root is in /opt/energia. Inside that file I modified line 32 (compiler.cpp.flags) and added the option. Notice that -std=c++11 is not supported (raises an error).
compiler.cpp.flags=-std=c++0x -c -g -O2 {compiler.mlarge_flag} {compiler.warning_flags} -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -MMD
Unfortunately I have zero experience with embedXcode :\
Mimic std::function
std::function is not provided, thus you have to write some sort of class that mimics it. Something like:
// callback.hpp
#ifndef CALLBACK_HPP_
#define CALLBACK_HPP_
template <class RET, class ARG>
class Callback {
RET (*_f)(ARG);
public:
Callback() : _f(0) { };
Callback(RET (*f)(ARG)) : _f(f) { };
bool is_set() const { return (_f) ? true : false; }
RET operator()(ARG a) const { return is_set() ? _f(a) : 0; }
};
#endif /* CALLBACK_HPP_ */
// sketch
#include "callback.hpp"
// | !! empty capture!
void setup() { // V
auto clb = Callback<int, char>([](char c) { return (int)c; });
if (clb.is_set())
auto b = clb('a');
}
void loop() {}
may do the work, and it uses a simple trick:
The closure type for a lambda-expression with no lambda-capture has a public non-virtual non-explicit const conversion function to pointer to function having the same parameter and return types as the closure type’s function call operator. [C++11 standard 5.1.2]
As soon as you leave the capture empty, you are assured to have a "conversion" to a function pointer, thus you can store it without issues. The code I have written:
requires a first template RET that is the returned type
requires a second template ARG that is one argument for the callback. In the majority of the case you may consider to use void* as common argument (cast a struct pointer in a void pointer and use it as argument, to counter-cast in the function, the operation costs nothing)
implements two constructors: the empty constructor initialize the function pointer to NULL, while the second directly assigns the callback. Notice that the copy constructor is missing, you need to implement it.
implements a method to call the function (overloading the operator ()) and to check if the callback actually exists.
Again: this stuff compiles with no warnings, but I don't know if it works on the MSP430, since I cannot test it (it works on a common amd64 linux system).

communication between a cpp file and an h file

Please consider the following
/*utils.h*/
#include <cstdio>
#include <iostream>
//#include some other files, including <string>
//ifndef ... and such macro
extern string configpath;
extern void writelog(string, string);
extern string get_fromfile(string, string);
//end the said macro
then we have
/*utils.cpp*/
//all necessary includes, including <string>
#include "utils.h" //they are in the same folder, as the following main .cpp
void writelog(string msg, string location = "lookinconfigfile")
{
if (location == "lookinconfigfile")
{
get_fromFile(configpath, "logpath");
//the function correctly returns the path to logfile, tested separatly.
}
...
}
string get_formFile(string flpt, string wht)
{...}
then in main.cpp, i include utils.h, and set the configpath to point to a file which holds a path to the logfile.
now g++ -c utils.cpp -std=c++11 produces utils.o
g++ -c main.cpp -std=c++11 produces main.o
before introducing the configpath as a global variable, by explicitly mentioning the configpath, that is, hard coding it to each occurrence, i was able to do this:
g++ main.o -o main
and that would generate main as an executable which would behave as expected.
But now i get this:
main.o: In function `writelog(std::string, std::string)':
main.cpp:(.text+0x2ce): undefined reference to `configpath
Also, if i keep the definition of get_fromFile in utils.cpp _after_ writelog, despite the prototype in utils.h, i get that get_fromFile is not defined.
where do i search looking for solutions?
edit: as user2079303 suggested, yes, it is utils.h, not utils.cpp, thank you.
edit2: as bobah mentioned, i actually have the cases correct in my code, just mistyped here. sorry.
You need to define your variable to let compiler know which object file to put it to. Mentioning it in the header file as extern string configpath; just tell compiler that somewhere there will be this variable, leave unresolved reference and let linker resolve it.
Add to your main.cpp:
string configpath;
In your final invocation to gcc, you only link main.o, but not utils.o.

GCC: how to tell GCC to put the 'main' function at the start of the .text section?

I've just started learning some ARM programming and I've got stuck in a slightly annoying problem. The toolchain I'm using to compile my sources is Sourcery CodeBench Lite 2013.05-23 (can be found here: https://sourcery.mentor.com/GNUToolchain/release2449)
What I would need is to tell GCC or LD or OBJCOPY to put the compiled bytecode of the 'main' function at the beginning of the .text section.
Is there any way to achieve this? (maybe through a linker script?)
Thank you
Solved the problem. For whoever faces it:
When compiling with GCC, add the -ffunction-sections option in the command-line. This will tell GCC to put each function in a separate section. The format of the section name will be .text.#function name#, without the # (that is, if the function belongs to the .text section [ which by default is true ]).
Secondly, use a linker script to order these "function-sections" into the final big .text section. As an example, putting the main function at the beginning of the .text section would result in an LD script that looks approximately like this:
ENTRY(main)
SECTIONS
{
.text :
{
*(.text.main);
*(.text*);
}
}
First, see how is the .text section defined in your gcc's default linker script (so you don't have to make your own), by calling it as:
gcc -Wl,-verbose
that will print out the default linker script. Mine shows this for the .text section:
/* text: Program code section */
.text :
{
*(.text)
*(.text.*)
*(.gnu.linkonce.t.*)
}
So in order to have the "main" function be the first in the .text section (and the rest be contiguous), you have to set the "section" attribute for all other functions. For example:
void main(void);
void funct1(....) __attribute__ ((section (".text.A")));
void funct2(....) __attribute__ ((section (".text.A")));
void funct3(....) __attribute__ ((section (".text.A")));
It's enough with "attributing" the function prototypes. That way, when you compile now, the "main" function will be the first one in the ".text" section and all others will follow on the immediately consecutive addresses.
If you want to place the ".text" section (i.e. "main" function) at a specific address (for example 0x1000), remember to link with:
gcc .... -Wl,-Ttext=0x1000
You can also just put 'main' in its own section using an __attribute__:
int main (void) __attribute__ ((section ("entry")));
and then in the ld file:
ENTRY(main)
SECTIONS
{
.text :
{
*(main)
*(.text)
}
}
There are plenty of other interesting __attributes__, read more about them here: http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html

How to find the address & length of a C++ function at runtime (MinGW)

As this is my first post to stackoverflow I want to thank you all for your valuable posts that helped me a lot in the past.
I use MinGW (gcc 4.4.0) on Windows-7(64) - more specifically I use Nokia Qt + MinGW but Qt is not involved in my Question.
I need to find the address and -more important- the length of specific functions of my application at runtime, in order to encode/decode these functions and implement a software protection system.
I already found a solution on how to compute the length of a function, by assuming that static functions placed one after each other in a source-file, it is logical to be also sequentially placed in the compiled object file and subsequently in memory.
Unfortunately this is true only if the whole CPP file is compiled with option: "g++ -O0" (optimization level = 0).
If I compile it with "g++ -O2" (which is the default for my project) the compiler seems to relocate some of the functions and as a result the computed function length seems to be both incorrect and negative(!).
This is happening even if I put a "#pragma GCC optimize 0" line in the source file,
which is supposed to be the equivalent of a "g++ -O0" command line option.
I suppose that "g++ -O2" instructs the compiler to perform some global file-level optimization (some function relocation?) which is not avoided by using the #pragma directive.
Do you have any idea how to prevent this, without having to compile the whole file with -O0 option?
OR: Do you know of any other method to find the length of a function at runtime?
I prepare a small example for you, and the results with different compilation options, to highlight the case.
The Source:
// ===================================================================
// test.cpp
//
// Intention: To find the addr and length of a function at runtime
// Problem: The application output is correct when compiled with: "g++ -O0"
// but it's erroneous when compiled with "g++ -O2"
// (although a directive "#pragma GCC optimize 0" is present)
// ===================================================================
#include <stdio.h>
#include <math.h>
#pragma GCC optimize 0
static int test_01(int p1)
{
putchar('a');
putchar('\n');
return 1;
}
static int test_02(int p1)
{
putchar('b');
putchar('b');
putchar('\n');
return 2;
}
static int test_03(int p1)
{
putchar('c');
putchar('\n');
return 3;
}
static int test_04(int p1)
{
putchar('d');
putchar('\n');
return 4;
}
// Print a HexDump of a specific address and length
void HexDump(void *startAddr, long len)
{
unsigned char *buf = (unsigned char *)startAddr;
printf("addr:%ld, len:%ld\n", (long )startAddr, len);
len = (long )fabs(len);
while (len)
{
printf("%02x.", *buf);
buf++;
len--;
}
printf("\n");
}
int main(int argc, char *argv[])
{
printf("======================\n");
long fun_len = (long )test_02 - (long )test_01;
HexDump((void *)test_01, fun_len);
printf("======================\n");
fun_len = (long )test_03 - (long )test_02;
HexDump((void *)test_02, fun_len);
printf("======================\n");
fun_len = (long )test_04 - (long )test_03;
HexDump((void *)test_03, fun_len);
printf("Test End\n");
getchar();
// Just a trick to block optimizer from eliminating test_xx() functions as unused
if (argc > 1)
{
test_01(1);
test_02(2);
test_03(3);
test_04(4);
}
}
The (correct) Output when compiled with "g++ -O0":
[note the 'c3' byte (= assembly 'ret') at the end of all functions]
======================
addr:4199344, len:37
55.89.e5.83.ec.18.c7.04.24.61.00.00.00.e8.4e.62.00.00.c7.04.24.0a.00.00.00.e8.42
.62.00.00.b8.01.00.00.00.c9.c3.
======================
addr:4199381, len:49
55.89.e5.83.ec.18.c7.04.24.62.00.00.00.e8.29.62.00.00.c7.04.24.62.00.00.00.e8.1d
.62.00.00.c7.04.24.0a.00.00.00.e8.11.62.00.00.b8.02.00.00.00.c9.c3.
======================
addr:4199430, len:37
55.89.e5.83.ec.18.c7.04.24.63.00.00.00.e8.f8.61.00.00.c7.04.24.0a.00.00.00.e8.ec
.61.00.00.b8.03.00.00.00.c9.c3.
Test End
The erroneous Output when compiled with "g++ -O2":
(a) function test_01 addr & len seem correct
(b) functions test_02, test_03 have negative lengths,
and fun. test_02 length is also incorrect.
======================
addr:4199416, len:36
83.ec.1c.c7.04.24.61.00.00.00.e8.c5.61.00.00.c7.04.24.0a.00.00.00.e8.b9.61.00.00
.b8.01.00.00.00.83.c4.1c.c3.
======================
addr:4199452, len:-72
83.ec.1c.c7.04.24.62.00.00.00.e8.a1.61.00.00.c7.04.24.62.00.00.00.e8.95.61.00.00
.c7.04.24.0a.00.00.00.e8.89.61.00.00.b8.02.00.00.00.83.c4.1c.c3.57.56.53.83.ec.2
0.8b.5c.24.34.8b.7c.24.30.89.5c.24.08.89.7c.24.04.c7.04.
======================
addr:4199380, len:-36
83.ec.1c.c7.04.24.63.00.00.00.e8.e9.61.00.00.c7.04.24.0a.00.00.00.e8.dd.61.00.00
.b8.03.00.00.00.83.c4.1c.c3.
Test End
This is happening even if I put a "#pragma GCC optimize 0" line in the source file, which is supposed to be the equivalent of a "g++ -O0" command line option.
I don't believe this is true: it is supposed to be the equivalent of attaching __attribute__((optimize(0))) to subsequently defined functions, which causes those functions to be compiled with a different optimisation level. But this does not affect what goes on at the top level, whereas the command line option does.
If you really must do horrible things that rely on top level ordering, try the -fno-toplevel-reorder option. And I suspect that it would be a good idea to add __attribute__((noinline)) to the functions in question as well.

Resources