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

Thomas Hellstrom thellstrom at vmware.com
Tue Apr 4 14:28:00 UTC 2017 

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.


> bleh, u_debug_symbol doesn't seem to manage to decode symbol names
> quite as well (at least on arm):
>
>
> aaaa bbbb backtrace follows:
>     0: /home/robclark/src/mesa/debug/lib64/gallium/msm_dri.so
> (debug_flush_capture_frame+0x38) [0x7f97d5c958]
>     1: /home/robclark/src/mesa/debug/lib64/gallium/msm_dri.so
> (debug_flush_alert+0xc4) [0x7f97d5cd4c]
>     2: /home/robclark/src/mesa/debug/lib64/gallium/msm_dri.so
> (fd_gmem_render_tiles+0x74) [0x7f97de65bc]
>     3: /home/robclark/src/mesa/debug/lib64/gallium/msm_dri.so
> (fd_batch_flush+0x148) [0x7f97de1d50]
>     4: /home/robclark/src/mesa/debug/lib64/gallium/msm_dri.so
> (fd_flush_resource+0x20) [0x7f97dead28]
>     5: /home/robclark/src/mesa/debug/lib64/gallium/msm_dri.so
> (dri_flush+0xac) [0x7f97d0005c]
>     6: /home/robclark/src/mesa/debug/lib64/libGL.so.1
> (loader_dri3_swap_buffers_msc+0x6c) [0x7f9883446c]
>     7: glxgears (main+0x3fc) [0x5592ba0fbc]
>     8: /lib64/libc.so.6 (__libc_start_main+0xe8) [0x7f9841a668]
>     9: ? (__libc_start_main+0xfa786f58) [0x8092ba14d8]
>
>
> versus this with u_debug_symbol:
>
> aaaa bbbb backtrace follows:
>     0: /home/robclark/src/mesa/debug/lib64/gallium/msm_dri.so
> (/home/robclark/src/mesa/debug/lib64/gallium/msm_dri.so(+0x411920)
> [0x7f8624a920]+0x38) [0x7f8624a958]
>     1: /home/robclark/src/mesa/debug/lib64/gallium/msm_dri.so
> (/home/robclark/src/mesa/debug/lib64/gallium/msm_dri.so(+0x411c88)
> [0x7f8624ac88]+0xc4) [0x7f8624ad4c]
>     2: /home/robclark/src/mesa/debug/lib64/gallium/msm_dri.so
> (/home/robclark/src/mesa/debug/lib64/gallium/msm_dri.so(+0x49b6b8)
> [0x7f862d46b8]+0x74) [0x7f862d472c]
>     3: /home/robclark/src/mesa/debug/lib64/gallium/msm_dri.so
> (/home/robclark/src/mesa/debug/lib64/gallium/msm_dri.so(+0x496d78)
> [0x7f862cfd78]+0x148) [0x7f862cfec0]
>     4: /home/robclark/src/mesa/debug/lib64/gallium/msm_dri.so
> (/home/robclark/src/mesa/debug/lib64/gallium/msm_dri.so(+0x49fe78)
> [0x7f862d8e78]+0x20) [0x7f862d8e98]
>     5: /home/robclark/src/mesa/debug/lib64/gallium/msm_dri.so
> (/home/robclark/src/mesa/debug/lib64/gallium/msm_dri.so(+0x3b4fb0)
> [0x7f861edfb0]+0xac) [0x7f861ee05c]
>     6: /home/robclark/src/mesa/debug/lib64/libGL.so.1
> (/home/robclark/src/mesa/debug/lib64/libGL.so.1(+0x4d400)
> [0x7f86d22400]+0x6c) [0x7f86d2246c]
>     7: glxgears (glxgears(main+0) [0x55816a6bc0]+0x3fc) [0x55816a6fbc]
>     8: /lib64/libc.so.6 (/lib64/libc.so.6(__libc_start_main+0)
> [0x7f86908580]+0xe8) [0x7f86908668]
>     9: ? (/lib64/libc.so.6(__libc_start_main+0)
> [0x7f86908580]+0xfad9ef58) [0x80816a74d8]

Here you'd want to parse the log file through addr2line.sh. It will
typically replace the cryptic hex code with source file and line number.
The output from a debug_flush section typically looks:

Reference of mapped buffer detected. Reference backtrace follows:
    debug_flush_alert at
/home/thomas/mesa-vmw/src/gallium/auxiliary/util/u_debug_flush.c:189
[0x7f66831fad20]
    debug_flush_cb_reference at
/home/thomas/mesa-vmw/src/gallium/auxiliary/util/u_debug_flush.c:281
[0x7f66831fb118]
    vmw_swc_mob_relocation at
/home/thomas/mesa-vmw/src/gallium/winsys/svga/drm/vmw_context.c:464
[0x7f668332f338]
    vmw_swc_surface_relocation at
/home/thomas/mesa-vmw/src/gallium/winsys/svga/drm/vmw_context.c:564
[0x7f668332f668]
    SVGA3D_vgpu10_SetVertexBuffers at
/home/thomas/mesa-vmw/src/gallium/drivers/svga/svga_cmd_vgpu10.c:1174
(discriminator 2) [0x7f668333a542]
    draw_vgpu10 at
/home/thomas/mesa-vmw/src/gallium/drivers/svga/svga_draw.c:612
[0x7f668333eb11]
    svga_hwtnl_prim at
/home/thomas/mesa-vmw/src/gallium/drivers/svga/svga_draw.c:946
[0x7f668333f61e]
    svga_hwtnl_simple_draw_range_elements at
/home/thomas/mesa-vmw/src/gallium/drivers/svga/svga_draw_elements.c:175
[0x7f66833403dc]
    svga_hwtnl_draw_range_elements at
/home/thomas/mesa-vmw/src/gallium/drivers/svga/svga_draw_elements.c:220
[0x7f668334050c]
    svga_vbuf_render_draw_elements at
/home/thomas/mesa-vmw/src/gallium/drivers/svga/svga_swtnl_backend.c:355
[0x7f6683370540]
**********************************
Map backtrace follows:
    debug_flush_capture_frame at
/home/thomas/mesa-vmw/src/gallium/auxiliary/util/u_debug_flush.c:92
[0x7f66831faabd]
    debug_flush_map at
/home/thomas/mesa-vmw/src/gallium/auxiliary/util/u_debug_flush.c:227
[0x7f66831faeaf]
    vmw_svga_winsys_buffer_map at
/home/thomas/mesa-vmw/src/gallium/winsys/svga/drm/vmw_buffer.c:356
[0x7f668332e44a]
    vmw_svga_winsys_surface_map at
/home/thomas/mesa-vmw/src/gallium/winsys/svga/drm/vmw_surface.c:148
[0x7f6683335be7]
    svga_buffer_hw_storage_map at
/home/thomas/mesa-vmw/src/gallium/drivers/svga/svga_resource_buffer.h:287
[0x7f66833523f4]
    svga_buffer_transfer_map at
/home/thomas/mesa-vmw/src/gallium/drivers/svga/svga_resource_buffer.c:254
[0x7f6683352b7c]
    u_transfer_map_vtbl at
/home/thomas/mesa-vmw/src/gallium/auxiliary/util/u_transfer.c:140
[0x7f668321dc02]
    pipe_buffer_map_range at
/home/thomas/mesa-vmw/src/gallium/drivers/svga/../../../../src/gallium/auxiliary/util/u_inlines.h:282
[0x7f66833708e7]
    pipe_buffer_map at
/home/thomas/mesa-vmw/src/gallium/drivers/svga/../../../../src/gallium/auxiliary/util/u_inlines.h:303
[0x7f6683370955]
    svga_swtnl_draw_vbo at
/home/thomas/mesa-vmw/src/gallium/drivers/svga/svga_swtnl_draw.c:74
[0x7f6683370ba3]
*********END OF MESSAGE***********

/Thomas

More information about the mesa-dev mailing list