Re: [Valgrind-users] building valgrind + perftools-lite linking error

[John R. <jr...@Bi...>]

Hi janjust,

>  I found that perftools-lite do not support static
> linking (kinda odd).
> There are no perf.a files to be linked statically with valgrind; however,
> perftools should work with static linking.
> 
> The perftools process is:
> build your application and retain object files, then use:
> $pat_build -O apa <executable>
> This gives a new executable to run.
> 
> However, I tried instrumenting the nulltool but get:
> ERROR: Missing required ELF section '.note.link' from the program
> ../none-amd64-linux

It would be good to know whether that complaint is from valgrind,
or from perftools, or from the app itself.
And "../none-amd64-linux" is a peculiar name for a program;
instead that usually designates an execution environment
by naming three relevant pieces.  In this case "amd64" is the hardware,
"linux" is the operating system, and "none" is some aspect that I don't know.

> 
> I presume this is somehow stripped from none-amd64-linux?
> 
> Could this line in the makefile have anything to do whit this?

I suppose it could, but the connection is not obvious.  Vary the command-line
parameters by removing each one individually (keeping the others), and see
what complaints you get.  Probably the individual results won't run,
but we're after hints from any warnings or error messages that might arise.

> 
>  523 # -Wl,--build-id=none is needed when linking tools with a linker that
> only
>  524 # knows -Ttext and not -Ttext-segment. Without this flag newer ld
> versions
>  525 # (2.20 and later) create a .note.gnu.build-id at the default text
> segment
>  526 # address, which of course means the resulting executable
>  527 # is unusable. So we have to tell ld not to generate that, with
>  528 # --build-id=none unless the linker supports -Ttext-segment.
>  529 TOOL_LDFLAGS_COMMON_LINUX = \
>  530   -static -nodefaultlibs -nostartfiles -u _start

Run "readelf --sections" on every binary file that contributes [including
by transitive closure] to the "final executable", and see where all the
".note.link" sections are.  See if any of them disappear before the end.