[Bug testsuite/10671] semok/twenty.stp takes 15 minutes on slow/low-memorry machine

["mjw at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

------- Additional Comments From mjw at redhat dot com  2009-09-22 09:56 -------
(In reply to comment #3)
> After this patch:
> 
> diff --git a/translate.cxx b/translate.cxx
> index 04a9247..c304178 100644
> --- a/translate.cxx
> +++ b/translate.cxx
> @@ -4482,7 +4482,7 @@ static void get_unwind_data (Dwfl_Module *m,
>  
>    // fetch .eh_frame info preferably from main elf file.
>    dwfl_module_info (m, NULL, &start, NULL, NULL, NULL, NULL, NULL);
> -  elf = dwfl_module_getelf(m, &bias);
> +  elf = (dwarf_getelf (dwfl_module_getdwarf (m, &bias)) ?: dwfl_module_getelf
> (m, &bias));
>    ehdr = gelf_getehdr(elf, &ehdr_mem);
>    scn = NULL;
>    while ((scn = elf_nextscn(elf, scn)))
> 
> the situation improves somewhat.

Unfortunately that doesn't work, since the dwarf elf file in a split debuginfo
scenario doesn't actually contain the actual .eh_frame section bits (the section
is there, but it is marked NO_BITS in that case). We really need the bits from
the main elf file .eh_frame section. exelib.exp has a test for this split
debuginfo case.

I don't believe .eh_frame sections contain any relocatable addresses, so it is
somewhat unfortunate that libdwfl decides to try to relocate things anyway.
Should we maybe open the main elf file directly ourselves, bypassing
dwfl_module_getelf()?

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=10671

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.