top button
Flag Notify
    Connect to us
      Site Registration

Site Registration

Valgrind with dynamically linked GCC plugin

+3 votes

I've been using the profiling tool valgrind for a while now. It requires an executable to run, i.e.

$ valgrind ./a.out

I want to use it on a dynamically linked GCC plugin, and list the time taken and the number of calls by each function used in the plugin. I am running the GCC plugin as follows:

 $ gcc -fplugin=./ myfile.c

When I run the following command, valgrind reports the memory leaks for only gcc and not for I need a way to run valgrind exclusively on my plugin, which is a .so file.

 $ valgrind gcc -fplugin=./ myfile.c
 $ gcc -fplugin=./ myfile.c -wrapper valgrind

Is it even possible to do that? I've searched up on this a lot but haven't found any concrete answer on it.

posted Jun 3, 2015 by Ankit

Share this question
Facebook Share Button Twitter Share Button LinkedIn Share Button

1 Answer

+1 vote

gcc is only a driver which runs other binaries to perform actual tasks: preprocessor, compiler, assembler, linker. You have to add --trace-children=yes option when starting gcc, or run it as a wrapper as you wrote above:

valgrind --trace-children=yes gcc -fplugin=./ myfile.c
answer Aug 12, 2015 by anonymous
Similar Questions
0 votes

is it possible to add a private extension to the core language (C/C++) by writing a gcc plugin?

The extension in mind is something like this


Later I want this be possible also inside statement headers, for example

for ([double d = 1.0; bool f = false;] size_t i = 0; i < vec.size(); ++i)

The scope of the so-defined variables shall be the same scope they are in, ie. in the for-loop case just the scope of the for-loop itself, much like the case with i.

+1 vote

My current compiler settings are

arm-none-eabi-gcc -Wall -mfpu=fpv4-sp-d16 -mfloat-abi=softfp -fshort-double-mcpu=cortex-m4 -mthumb -Qn -Os -finstrument-functions -mlong-calls -c temp.c -o temp.o
so on for temp1, temp2... Etc

I am compiling multiple C files. and linker settings are

ld -r temp.o -o one.o
so on for temp1, temp2... Etc

I am linking multiple .O files. Also I am using linker script i.e link.txt (invoked externally as below)

ld -cref -Map map.txt -S -T link.txt -temp.o -lm -lc -lgcc
arm-none-eabi-gcc -Wall sample.o -O Firmware.abs

Now, At output I get .abs file of 140KB.

My Questions are
1. How to optimize (reduce size of .abs) by using compiler or linker specific options?
2. There are Number of NOT used global variables and Blank Function Calls in my C files (NO Dead Code!!!!). Is it possible to perform some link time optimization.
3. Please Elaborate as I am new to this, I have referred sites, gcc help and tried some "lto" options but NO reduction is size.
4. I also tried using -fdata-sections -ffunction-sections
But It has INCREASED my firmware.abs file size from KB to MB (yes it is MB!!!!) I also wondered WHY?
I am using codesourcery arm toolchain evaluation. It has gcc version 4.5.2

+1 vote
struct xx
 int x;
 struct yy *p;
 int s;
 int s;

int main()
 struct xx xyz;
 return 0;

the above code compile well without any warning. Here my question is
1. How can I distinguish two 's' variable.
2. What is use case.

+1 vote

I'm writing a gcc plugin to find out target basic blocks to branch instructions, and need to match instructions and basic blocks with compiled binaries, so I decided to explicitly annotate all the branch
instructions and basic blocks with named labels, then from the compiler plugin I assign named labels to branch instructions and basic blocks, and from symbol table I can get offset to these instructions
and basic blocks. Is this the right way to do it, or I shouldn't do this task in compiling phase?

When I was trying with this method, I wrote a plugin with some code like this:

unsigned int
 rtx insn, bb_start, bb_end;
 basic_block bb;
 bb_start = gen_label_rtx();
 LABEL_NAME(bb_start) = "BB Start";
 LABEL_NUSES(bb_start) = 1;
 bb_end = gen_label_rtx();
 LABEL_NAME(bb_end) = "BB End";
 LABEL_NUSES(bb_end) = 1;

 emit_label_before(bb_start, BB_HEAD(bb));
 emit_label_after(bb_end, BB_END(bb));

 return 0;

I insert this pass before final pass. But when compiling C program with this plugin, I got error:

foo.c:7:1: internal compiler error: in final, at final.c:1958

It seems this is not the correct way to insert labels. Am I using emit_label_* in a wrong way, at wrong time, or I'm totally in the wrong direction?

0 votes

Can I use gcc as well as java compiler on a single desktop?