This is the mail archive of the
frysk@sources.redhat.com
mailing list for the frysk project.
Re: remote dwarf info using libunwind
Alexandre Oliva wrote:
On Sep 17, 2006, Alexandre Oliva <aoliva@redhat.com> wrote:
On Sep 15, 2006, Alexandre Oliva <aoliva@redhat.com> wrote:
Here's the patch that fixes line numbers for main() and addresses
printed in backtraces for PCs in modules that don't have unwind info.
I wonder if I should set an upper limit on the symbol name size
instead of keeping retrying until memory is really exhausted or so.
Thoughts?
Here's another approach I thought of, that involves a change in the
interface of the get_proc_name callback, requiring it to cope with a
NULL buf and zero buf_len. We could do away with the latter, and pass
in ~(size_t)0 for essentially the same effect, but since it hardly
makes any difference, I thought I'd go for both.
Is this ok for frysk? It should reduce the stack size requirements
when unwinding through ridiculously long symbol names.
Ok for frysk?
for frysk/frysk-imports/libunwind/ChangeLog
from Alexandre Oliva <aoliva@redhat.com>
* src/elfxx.c (lookup_symbol): Cope with NULL buf and zero buf_len.
* src/mi/Gget_proc_name.c (intern_string, get_proc_name): Likewise.
* src/hppa/Gget_proc_info.c (unw_get_proc_info): Use it.
* src/x86/Gget_proc_info.c (unw_get_proc_info): Likewise.
* src/x86_64/Gget_proc_info.c (unw_get_proc_info): Likewise.
* doc/unw_get_proc_name.tex: Document NULL buf and zero buf_len.
* doc/unw_create_addr_space.tex (get_proc_name): Likewise.
* doc/unw_get_proc_name.man: Rebuilt.
* doc/unw_create_addr_space.man: Likewise.
Ping?
Hi Alex,
I guess *most* of us were hesitating because we don't feel we are
qualified to judge the code. If it works ok on your system and does not
break any tests I would say check it in so the rest of us can test it.
Thanks for your efforts here, Alex.
Rick