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

Rob Clark robdclark at gmail.com
Tue Apr 4 17:12:19 UTC 2017


On Tue, Apr 4, 2017 at 12:10 PM, Thomas Hellstrom <thellstrom at vmware.com> wrote:
> On 04/04/2017 05:36 PM, Rob Clark wrote:
>> On Tue, Apr 4, 2017 at 10:28 AM, Thomas Hellstrom <thellstrom at vmware.com> wrote:
>>> On 04/04/2017 04:06 PM, Rob Clark wrote:
>>>> On Tue, Apr 4, 2017 at 10:00 AM, Rob Clark <robdclark at gmail.com> 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.
>>>>>>
>>>>> fwiw, I added a hash-table:
>>>>>
>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_freedreno_mesa_commits_wip-2Dlibunwind&d=DwIFaQ&c=uilaK90D4TOVoH58JNXRgQ&r=wnSlgOCqfpNS4d02vP68_E9q2BNMCwfD2OZ_6dCFVQQ&m=VIINenNexQBSdAAjE5gNpegAuq9f_KOvkScYgqyZchQ&s=imNnOqL2QvjC7ok9q_QrCXSDr6AXpVgK4MYos9ZcyoM&e=
>>>>>
>>>>> It seems to work, but my hacked up test doesn't collect more
>>>>> stacktraces than it prints so haven't really tested it from
>>>>> performance standpoint.
>>>>>
>>>>> Possibly it could re-use debug_symbol_name_cached() instead, or at
>>>>> least not duplicate the hashtable..
>>>>>
>>> So, with your patches including the hash table, I'm up to speed again.
>>> But addr2line.sh doesn't work.
>>>
>> Do you have an example of a stacktrace before addr2line.sh?  I'm
>> trying to figure out the regexp's in that script but I guess it would
>> be easier if I knew what it was matching against.
>>
>> BR,
>> -R
>
> Here it goes. I think what's translated by addr2line.sh is the part
> starting the line up to the closing parentheses. The rest of the line is
> let through as it is.
>

ok, after bashing my head against regexps for a bit, and eventually
getting that part working, I realized that the addr2line trick needed
relative offset within the DSO.  So we had to diverge a bit from the
format used by xserver/weston.  At that point, it was easier to just
drop the leading stackframe number so that it works as-is with
addr2line.sh

I've pushed an extra patch to my wip-libunwind branch to tweak the
output to work with addr2line.sh

https://github.com/freedreno/mesa/commits/wip-libunwind

BR,
-R


More information about the mesa-dev mailing list