On 04/04/2017 07:12 PM, Rob Clark wrote:
> On Tue, Apr 4, 2017 at 12:10 PM, Thomas Hellstrom <thellst...@vmware.com>
> wrote:
>> On 04/04/2017 05:36 PM, Rob Clark wrote:
>>> On Tue, Apr 4, 2017 at 10:28 AM, Thomas Hellstrom <thellst...@vmware.com>
>>> wrote:
>>>> On 04/04/2017 04:06 PM, Rob Clark wrote:
>>>>> On Tue, Apr 4, 2017 at 10:00 AM, Rob Clark <robdcl...@gmail.com> wrote:
>>>>>> On Tue, Apr 4, 2017 at 8:45 AM, Thomas Hellstrom <thellst...@vmware.com>
>>>>>> wrote:
>>>>>>> On 04/04/2017 02:34 PM, Rob Clark wrote:
>>>>>>>> On Tue, Apr 4, 2017 at 1:49 AM, Thomas Hellstrom
>>>>>>>> <thellst...@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://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_freedreno_mesa_commits_wip-2Dlibunwind&d=DwIFaQ&c=uilaK90D4TOVoH58JNXRgQ&r=wnSlgOCqfpNS4d02vP68_E9q2BNMCwfD2OZ_6dCFVQQ&m=izk41sNzPd9GEwoptJ7x3vK9EgrFWrOdYHqw5_LQ3kU&s=8hv-C4A14nMrGosCL_38GBE1OLHMs3y4V_G5T26B_lc&e=
>
>
> BR,
> -R
Yes, with this change I can get a consistent output from addr2line.sh,
and debug_flush appears to run fast enough.
I get the following compilation warning:
util/u_debug_stack.c: In function 'symbol_name_cached':
util/u_debug_stack.c:94:7: warning: ignoring return value of 'asprintf',
declared with attribute warn_unused_result [-Wunused-result]
asprintf(&name, "%s%s", procname, ret == -UNW_ENOMEM ? "..." : "");
Otherwise I'm OK with having libunwind as the default backtrace
provider, although I still think we should fall back to glibc
backtrace() when libunwind is not available.
/Thomas
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
