I have decision tree classifer class implemented in C++ and I want to profile only C++ shared library of my decision tree class. I am using linux perf tool but I do not want to profile the whole application just the shared library which I have created for decision tree class.
is it possible to generate perf.data for shared library and then get a flame graph?
any help will be highly appreciated in this regards,
Arslan
Related
since dlopen uses libdl.so , but i am working on standalone application which do not use OS support, so my idea is to implement dlopen directly using coding is there any
Loading shared libraries is intrinsically dependent on the operating
system's runtime loader and in turn on the operating system's executable file format and its process construction model. There is no OS-independent way to do it.
The GNU source code of dlopen is of course
freely available, but that does not make it independent of an operating system.
The maximum degree of OS independence you can achieve in C is obtained by
restricting yourself to software that you can write entirely with the
resources of the Standard C Library. The Standard C Library does not contain
dlopen or any equivalent functionality, because such functionality is
intrinsically OS-dependent.
As your question is tagged Linux, it is not quite clear why you would want your application
to be independent of OS support that is provided by Linux.
Suppose one is using the stackbuild tool to make a Haskell library (importing packages from Hackage, and so forth) to be used with a C/C++ project in which main is located in C/C++.
Supposing your project is named Lib.hs (which uses external libraries from hackage), is there a way to use stack to export your Lib.o, Lib.hi, and Lib_stub.h to be consumed by a C/C++ compiler like gcc or g++?
EDIT: A related question might be: "how can one use Stack as a build tool to be used with a Haskell & C/C++ project in which main is located in C/C++?
EDIT2: Upon reflection, one way to solve this problem would be to use Stack as usual, but migrate your C/C++ main function to Haskell. Is this the best way to do it? Are there huge performance costs to this or anything I should be aware of?
Stack can't really do this on its own.
There's support for generating so called "foreign libraries" added to Cabal, but it's not in a released version, yet. See commit 382143 This will produce a shared library that dynamically links against the dynamic versions of each Haskell package used.
You can build your package with stack and then after the fact you can assemble a single native library. In the Galua project we do this with a custom Setup.hs and a separate linking script.
The result of this linking process is that you get a standalone statically linked library suitable for inclusion in a C project: libgalua.a.
Do note that for creating standalone libraries on Linux suitable for being linked into a shared library that you'll need to recompile GHC to generate PIC static libraries (macOS does this by default).
I consistently implement an ITreeNode interface on all my tree structures. It would be excellent to have a vizualizer available when debugging that would display a tree structure in a treeview. Apart from writing my own from scratch, is there any open source vizualizer out there that could be adapted to recognize my ITreeNode interface?
Take a look at the JsonViewer at http://jsonviewer.codeplex.com/ which provides a tree visualizer for Json String.
I have modified the same for my project use to visualize my objects as tree and you can try the same.
Is it possible to modify a shared library (.so) in Linux without getting its source code???
I know about LD_PRELOAD, but is that useful for functions that are used IN the shared library itself???
Is there a way to decompile/disassemble and then recompile/reassemble binary ELF files?
Modifying applications is difficult to get right even with all the available documentation, code and support. Attempting to modify an application in binary form, (presumably) with no debug symbols, without documentation (judging by the fact you don't have the code) is therefore a much more arduous and risky undertaking.
Application reverse engineering is difficult, but can be done given enough resources, determination, tools and knowledge: all of this hinges on having a sufficiently valuable goal.
The interpreter and dynamic compiler would be for testing/prototyping and when im done testing i use the static compiler.
Java has all of these - the stock Sun JVM has both an interpreter and dynamic compiler, and the GNU Compiler for Java (GCJ) can statically compile to machine code.
There are many.
One such language is Objective Caml. Let's check it against your requirements:
High-level language: Caml supports functional, object-oriented, and imperative styles of programming.
Interpreter: The ocaml system is a read-evaluate-print loop.
dynamic compiler: On platforms that support dynamic loading, ocamlrun can link dynamically with C shared libraries (DLLs).
static compiler: Available through the -linkall flag in the compiler.
Multimedia: There are libraries for 2-d graphics, 3-d graphics, audio, and video.
The bigger question is finding the best tool for your job. Many languages meet those requirements, but the most used languages have the best documentation and the most tested bindings to libraries. If you're going to use a language like Caml, there should be some overriding benefit to that language that can't be found in other languages.
Good luck!
The best option for you depends on the kind of your application. If it is a real-time program, then just stay with C++ (or ever with C) because no high-level language like Ruby/Perl/Python will beat them in this domain. But if the complexity of your future program is high enough, the best option I see in Python + PyOpenGL (for graphics) +PyOpenAL (for sound) and PyODE (for real-time physics). Actually, Python's VM is fast enough but you can also (with some efforts) compile it into a platform-dependent optimized code.
Alternatively you can use PyGame for 2D graphics and a way comfortable sound/music management.