[Mesa-dev] [PATCH 2/2] gallium/util: libunwind support

[Thomas Hellstrom]

On 04/04/2017 02:49 PM, Rob Clark wrote:
> On Tue, Apr 4, 2017 at 8:45 AM, Thomas Hellstrom <thellstrom at vmware.com> wrote:
>> On 04/04/2017 02:34 PM, Rob Clark wrote:
>>> On Tue, Apr 4, 2017 at 1:49 AM, Thomas Hellstrom <thellstrom at vmware.com> wrote:
>>>> But one more worrying thing is that with these fixes, debug_flush gets
>>>> too slow to be usable. I get about one frame every 5 seconds from Ubuntu
>>>> compiz. The culprit seems to be unw_get_proc_name(). Is there a way we
>>>> can save intermediate information during backtrace capture and call this
>>>> function at printout time?
>>> btw, is it common to capture many more backtraces than you print?
>>> (Just to check if defering the unw_get_proc_name() would actually help
>>> anything..)
>> Yes. The debug_flush functionality captures the backtrace on each map in
>> case someone would flush when mapped or try a recursive map. Only then
>> they are printed.
>>
>> FWIW in u_debug_symbol.c, José has implemented a hash table for name
>> lookups. Perhaps one solution would to save the IP and insert the
>> function name in the hash table with the IP as key.
> Yeah, this might work.. I'm just digging through the libunwind code to
> see if there is a better way (since in theory it should be possible to
> defer the symbol lookup quite easily.. although even then a hashtable
> sound like it could improve things)
>
> fwiw, if we end up going the backtrace() route, I noticed
> https://urldefense.proofpoint.com/v2/url?u=https-3A__manned.org_unw-5Fbacktrace_e7940441&d=DwIFaQ&c=uilaK90D4TOVoH58JNXRgQ&r=wnSlgOCqfpNS4d02vP68_E9q2BNMCwfD2OZ_6dCFVQQ&m=jG5LQNduxtu9nyZQ5feQ788BZ1q5fkP6HmY3tmTbe_U&s=EdRhwfvtkUAKaANSnmPXmAywHHtBb1_B-DaM_H-J6PI&e=  .. perhaps that could
> provide a fallback backtrace() implementation on libc's which don't
> have backtrace()?

Sure. However in that case it seems problematic to get a decent
file-offset printout. We'd only get the hex pointer.

/Thomas

> BR,
> -R