On Fri, Apr 7, 2017 at 5:06 AM, Thomas Hellstrom <thellst...@vmware.com> wrote: > Hi, Rob, > > 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 > > Could you push these to mesa master? >
ok, done.. I was going to try to look into backtrace() fallback and fix that warn, but given that I haven't had time to do that yet, and that those three patches at least improve things, I guess it makes sense to push as-is. BR, -R _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
