On 24 August 2014 17:20, Josef Weidendorfer <josef.weidendor...@gmx.de> wrote: > Am 23.08.2014 um 14:56 schrieb Dan Liew: >>> The instruction address you specify below is always the same as the line >>> number. That makes not much sense. The instruction address is needed >>> for KCachegrind to show annotated machine code, using "objdump <binary>", >>> but your example does not specify a binary file using "ob=" anywayl >> >> On a slightly related note is it possible to specify an assembly file >> rather than an object file? For example If I had a C program (say >> foo.c) and its corresponding LLVM IR (foo.ll). I would like to display >> both the C source code and the foo.ll file. When I tried using >> obj=foo.ll however KCachegrind tried using objdump on that file and >> gave up because foo.ll is just text and not a binary. > > Currently there is no such option, and the "instr" subposition was meant > to be used with objdump. > > Perhaps it would be interesting to have a KCachegrind config option > (or specified in the header of a callgrind file) > which specifies what to do with a specific subposition type, instead of > running it through "objdump". Not sure yet what would cover most use > cases. For you, just the file and line number would be enough?
Sorry. I've probably confused things slightly. For the main project I'm currently working yes using only the line number is fine because my interpreter only works at the source level. With your help I now have jump information being shown correctly in Kcachegrind so I will definitely be outputting profiling information in the callgrind format :) The reason I was asking was because I was looking at another project (which was what inspired me play with KCachegrind) called KLEE[1]. This tool executes LLVM IR that comes from C programs, so there is an original source (e.g. foo.c) and the corresponding LLVM IR (e.g. foo.ll). Both of these are text files and I observed that the callgrind files that KLEE was emitting set ``ob=`` to the LLVM IR file and ``fl=`` to the original C source file. As I mentioned before this doesn't work as the author of KLEE intended because Kcachegrind tries to treat foo.ll as a object file rather than as a text file. In this case I like to think of LLVM IR as being similar to assembly so using the instr subposition with absolute line numbers feels fairly natural. KCachegrind could be taught to try and infer if ``ob=`` is really an object file or if it is text by looking for magic numbers (like the file command does) and then doing the appropriate thing. I think it would be nicer if the Callgrind file could optionally specify what to do with the instruction subposition type as you suggested. Just allowing obj to be plain text might be enough flexibility because this allows someone who wants to use their own disassembler (e.g. llvm-objdump) or no disassembler at all to run whatever tools they want on their object file to produce a text file before profiling. Then they can use the instruction subposition in the callgrind file can just refer to lines in this text file. You could have an option like # Objects are plain text obj_is_plain_text=1 in the callgrind file (which is by default 0) to specify that all object files are plain text files. You could go further and specify the tool to use for object files in the callgrind file but then you run into the problem that kcachegrind might not know how to parse the output so I think just allowing the object file to be plain text might be the simplest thing to do. There certainly isn't a rush for the feature like this but I think it would be a nice addition. Thanks, Dan [1] http://klee.llvm.org ------------------------------------------------------------------------------ Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ _______________________________________________ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
