That is used by cus__find_function_by_addr & cu__func_function_by_addr.
First user is pfunct --addr, but this is really for pfunct --annotate, that
will process a perf.data file generated by 'perf report', load the debugging
info and regenerate the functions (pfunct -TVi like) that had hits, using
libdisasm to show the assembly code, etc.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Replicating the comment added to the source code:
No sense in adding an anonymous struct to the list of structs already
printed, as we look for the name... The right fix probably will be to
call class__fprintf on a in-memory FILE, do a hash, and look it by full
contents, not by name. And this is needed for CTF as well, but its late
now and I'm sleepy, will leave for later...
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
I wasn't especifying the optimization level and the default, despite
using -Wall, was for this so simple case not to be warned about, so
now I'm using -O2.
Alexandre provided a patch initializing the variables to NULL, so that
when we called cus__delete it would bail out and not possibly act on
a random value, I preferred to add extra goto labels and do the exit
path only on the resources that were successfully allocated/initialized,
avoiding, for instance, to call dwarves_exit() if dwarves_init() wasn't
called, which wasn't a problem so far, but could be in the future.
Reported-by: Alexandre Vassalotti <alexandre@peadrop.com>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Fixing this comment,that only appears if one specifies -ON (N >= 2),
despite using -Wall:
strings.c: In function ‘strings__compare’:
strings.c:61: warning: dereferencing type-punned pointer will break strict-aliasing rules
strings.c stores a string_t on the are allocated by tsearch, so do it by
casting to unsigned long, that has a size > than string_t. No need for
the contortionism that was there before, that was plain silly.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Kinda brown paper bag one, and the thanks goes to C++ and the boost
library for providing such beautiful test cases as:
virtual int undefine(class
grammar_helper<boost::spirit::grammar<boost::detail::graph::dot_skipper,
boost::spirit::parser_context<boost::spirit::nil, class
grammar<boost::detail::graph::dot_skipper,
boost::spirit::parser_context<boost::spirit::nil_t> > *); /*
linkage=_ZN5boost6spirit4impl14grammar_helperINS0_7grammarINS_6detail5graph11dot_skipperENS0_14parser_contextINS0_5nil_tEEEEES6_NS0_7scannerINS0_10multi_passISt16istream_iteratorIccSt11char_traitsIcElENS0_19multi_pass_policies14input_iteratorENSH_11ref_countedENSH_12buf_id_checkENSH_9std_dequeEEENS0_16scanner_policiesINS0_27no_skipper_iteration_policyINS0_29inhibit_case_iteration_policyINS0_28skip_parser_iteration_policyIS6_NS0_16iteration_policyEEEEEEENS0_12match_policyENS0_13action_policyEEEEEE8undefineEPSA_
*/
;-)
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
JAVA support needs to be checked, but from a very quick skim it
looks ok'ish.
First detected with /usr/bin/fstack from frysk.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
So far all of these tags had just an abstract origin, so we only needed
to print the function it pointed to, but we need to treat it as an
DW_TAG_subprogram... fix it later, after 1.8, for now just dive in and
collect the types.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
In reponse to https://bugzilla.redhat.com/show_bug.cgi?id=497285 I
included the header files that are needed by the dwarves*.h files
and moved them to /usr/include/dwarves.h.
The CTF work is not completed yet, but the non-CTF related improvements
(progressive loading of CUs, etc) are worth a release till I can get back to
dedicate solid time for developing these tools again.
Reported-by: Masatake YAMATO <yamato@redhat.com>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Sharing the same space with abstract_origin, so that we can remove the last
Dwarf_Off in dwarf_fprintf.c.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
We do this by just creating a strlist with all the functions that are in
section ".init.text", as found out by looking at the symtab.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
In the past we did integer testing, and testing against 0 was no problem, but
now they return NULL and we are back using strcmp, oops.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
I.e. the operation may fail because the string is already there or
because there wasn't enough memory.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
So that we can more early return if we can't process files for some supported
debugging format and as well release all resources allocated when dwarves__exit
is called.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
There is still the problem of handing the strings table to the CTF encoder, but
that will be fixed another day.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
So that we can use the strings in ".strtab" directly, without duplicating them
on the global strings table.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Instead pass thru cu__strings(cu, i) so that we can figure out if the
underlying debugging format handler can do that more efficiently, such as by
looking up directly the ELF section ".strtab".
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
It ain't gonna be like that soon, when every cu that comes from a CTF file will
have all its strings_t pointing to strings in .strtab.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Such as signed, etc. This is in preparation for using directly ctf_strings.
Instead of duplicating it in the global strings table.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
That became cached when we moved to CTF like bitfields, i.e. each bit size
creates a new type so that the encoding for class members can have just the
name, type and bit_offset.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
ctracer was segfaulting due to this problem.
Reported-by: Breno Leitão <leitao@linux.vnet.ibm.com>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Temporary hack till I figure out how to do more filtering on the variables on
the symtab that aren't in the DWARF info.
Problem is that if we don't put something on the table at encode time, we won't
find it at decode time, when we don't have DWARF to notice that its not there
because its not in DWARF.
We then discard it at load time, as "void foo;" doesn't make sense.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Arnaldo Carvalho de Melo