Dave,
On Sat, Feb 4, 2017 at 9:15 PM, Dave Watson <davejwat...@fb.com> wrote:
> Currently we only look at the current image to resolve function names,
> which requires debug info. Often the debug info is split to a different
> file. os-linux.c does look in some distro's path in /usr/lib/debug%s,
> this diff will also follow the commonly used .gnu_debuglink section.
> ---
> src/elfxx.c | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
>
> diff --git a/src/elfxx.c b/src/elfxx.c
> index 25bd5a2..7b05f3f 100644
> --- a/src/elfxx.c
> +++ b/src/elfxx.c
> @@ -312,11 +312,27 @@ elf_w (get_proc_name) (unw_addr_space_t as, pid_t pid,
> unw_word_t ip,
> unsigned long segbase, mapoff;
> struct elf_image ei;
> int ret;
> + Elf_W (Shdr) *shdr;
>
> ret = tdep_get_elf_image (&ei, pid, ip, &segbase, &mapoff, NULL, 0);
> if (ret < 0)
> return ret;
>
> + shdr = elf_w (find_section) (&ei, ".gnu_debuglink");
> + if (shdr) {
> + char debug_path[PATH_MAX];
> + char *link = ((uint8_t *) ei.image) + shdr->sh_offset;
> + size_t link_len = shdr->sh_size;
> +
> + strncpy(debug_path, link, link_len);
Unfurtnatly, interpreting .gnu_debuglink is not that simple. I refer here to
https://sourceware.org/gdb/onlinedocs/gdb/Separate-Debug-Files.html
At least it is important, the the .gnu_debuglink should not contain
any path components at all. Thus using .gnu_debuglink verbatime wont
result in any sane path.
Also I think the code in os-linux.c should loose its current
/usr/lib/debug code.
Bert
> + Debug(1, "Found debuglink section, following %s len %i\n", debug_path,
> link_len);
> + munmap (ei.image, ei.size);
> +
> + ret = elf_map_image(&ei, debug_path);
> + if (ret < 0)
> + return ret;
> + }
> +
> ret = elf_w (get_proc_name_in_image) (as, &ei, segbase, mapoff, ip, buf,
> buf_len, offp);
>
> munmap (ei.image, ei.size);
> --
> 2.8.0-rc2
>
_______________________________________________
Libunwind-devel mailing list
Libunwind-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/libunwind-devel
