This is the mail archive of the
frysk@sources.redhat.com
mailing list for the frysk project.
Re: remote dwarf info using libunwind
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?
--
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
Secretary for FSF Latin America http://www.fsfla.org/
Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org}