DW_OP_addrx/constx and GNU DebugFission DW_OP_GNU_addr/const_index take
as argument an index into the .debug_addr section for the associated CU.
This index gets resolved through dwarf_getlocation_attr. A new fake addr
CU is created per Dwarf for use with this new attribute. For split DWARF
files, t
dwarf_highpc can use any address FORM, not just DW_FORM_addr. Just try
whether the address can be resolved as address. Always set error when
attribute couldn't be found or resolved. When calculating the base
address for a CU don't try to second guess the error code, just treat
an error the same as
On Fri, 2018-05-18 at 12:58 +0200, Mark Wielaard wrote:
> Split DWARF .dwo files do contain a .debug_line section, but only with
> the file table, there is no actual line program. Also split DWARF CU DIEs
> don't have a DW_AT_stmt_list attribute. To get at the file (and dir) table
> for a split uni
Hi,
On Mon, 2018-05-21 at 10:26 +0200, Justin Cinkelj wrote:
> Is it possible to get stack backtrace into KVM VM from the host side?
> So
> if I run './stack -p PID' (stack from elfutilfs
> https://sourceware.org/elfutils/), I get backtrace of some process. I
> would like to do the same for VM.
Something like that was suggested at KVM devel list too. I was able to
get an useful backtrace for a trivial VM (a single ELF file, VM code
runs directly from (virtual) physical memory). Well, that was more to
learn a bit about elfutils than anything else. A more realistic VM will
be more diffi
On Sat, May 19, 2018 at 04:03:51PM +0200, Mark Wielaard wrote:
> GNU DebugFission split dwarf handles DW_FORM_sec_offset specially for
> attributes that point to ranges. The .debug_ranges section is not in
> the .dwo file, but in the main/skeleton object file. The sec_offset is
> not relocated (in
