This is the mail archive of the mailing list for the frysk project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: remote dwarf info using libunwind

On Sep 17, 2006, Alexandre Oliva <> wrote:

> On Sep 15, 2006, Alexandre Oliva <> 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  <>

> 	* 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/ Rebuilt.
> 	* doc/ Likewise.


Alexandre Oliva
Secretary for FSF Latin America
Red Hat Compiler Engineer   aoliva@{,}
Free Software Evangelist  oliva@{,}

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]