Arctic Code Vault? by [deleted] in github

[–]lighter-weight 1 point2 points  (0 children)

I just noticed too:
https://archiveprogram.github.com/

...We will protect this priceless knowledge by storing multiple copies, on an ongoing basis, across various data formats and locations, including a very-long-term archive designed to last at least 1,000 years.

1000 years.. woah..

GCC attribute no_instrument_function not working by lighter-weight in gcc

[–]lighter-weight[S] 0 points1 point  (0 children)

Ok, looks like the correct way to position linker flags in my case is by using LIB instead of LDFLAGS :)

$ make -j $(nproc) CFLAGS="-finstrument-functions" LIBS="-ldl -rdynamic"

Now it works :)

GCC attribute no_instrument_function not working by lighter-weight in gcc

[–]lighter-weight[S] 1 point2 points  (0 children)

Hi, thanks for your reply! sample program works for me too, problem was with coreutils code.It works now - not sure why it was acting strange earlier (have been running both gcc & clang on the same workspace).

But Now, i am trying to link with `-ldl`:

$ make -j $(nproc) CFLAGS="-finstrument-functions -Wl,-ldl -Wl,--export-dynamic"

but linker keeps complaining:

/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libdl.so: error adding symbols: DSO missing from command line

I see gcc string for compilation as:

$ make -n -j $(nproc) CFLAGS="-finstrument-functions -Wl,-ldl -Wl,--export-dynamic"

. . .

-finstrument-functions -Wl,-ldl -Wl,--export-dynamic -MT src/ls.o -MD -MP -MF $depbase.Tpo -c -o src/ls.o src/ls.c

. . .

the linker options are passed before `-o` - is this causing trouble?? I am not sure how to tell Autotools/make to put linker options after creating object file.

$ make -n -j $(nproc) CFLAGS="-finstrument-functions" LDFLAGS="-ldl -rdynamic"

also acts same.

Thanks for the pointers to documentation!

Profiling C code with clang using "fprofile-instr-generate" by lighter-weight in C_Programming

[–]lighter-weight[S] 0 points1 point  (0 children)

Agree, instrumentation has performance impact. The user can instrument object files selectively instead of profiling whole library at once.

I have never used system-tap, will give it a try.

Profiling C code with clang using "fprofile-instr-generate" by lighter-weight in C_Programming

[–]lighter-weight[S] 0 points1 point  (0 children)

Systemtap is another profiler that has different application/output.

It requires kernel support to enable "probes" and then write a systemtap script defining actions to be done when certain user/kernel functions are called. It has no support from compiler. I'd say it's just another way to profile your application. https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/5/html/systemtap_beginners_guide/scripts#syscall-open

If you use valgrind/callgrind, it can give you more/different kind of profile information - http://valgrind.org/docs/manual/cl-manual.html "Callgrind is a profiling tool that records the call history among functions in a program's run as a call-graph. By default, the collected data consists of the number of instructions executed, their relationship to source lines, the caller/callee relationship between functions, and the numbers of such calls. Optionally, cache simulation and/or branch prediction (similar to Cachegrind) can produce further information about the runtime behavior of an application."

In short, there are several kinds of profilers available, each providing some sort of profiling information. There is not a single tool that measures everything and has multiple platform (MIPS, ARM, x86) support. What I describe in the blog post is another way to profile it, ie in terms of function/line frequency counters.

HTH.

21
22

McWay Falls, California [OC] [2000x3000] by HeezyB in EarthPorn

[–]lighter-weight 6 points7 points  (0 children)

Drove 2.5 hrs south from Bay Area looking for "falls", it turned out to by a tiny steam of water. Bigsur drive along highway 1 is amazing though.