On Tue, Apr 4, 2017 at 8:06 AM, Rob Clark <robdcl...@gmail.com> wrote: > On Tue, Apr 4, 2017 at 6:28 AM, Emil Velikov <emil.l.veli...@gmail.com> wrote: >> On 4 April 2017 at 10:00, Thomas Hellstrom <thellst...@vmware.com> wrote: >>> On 04/03/2017 11:09 PM, Rob Clark wrote: >>>> On Mon, Apr 3, 2017 at 4:57 PM, Rob Clark <robdcl...@gmail.com> wrote: >>>>> On Mon, Apr 3, 2017 at 4:06 PM, Thomas Hellstrom <thellst...@vmware.com> >>>>> wrote: >>>>>> On 04/03/2017 07:33 PM, Thomas Hellstrom wrote: >>>>>>> On 04/03/2017 07:13 PM, Rob Clark wrote: >>>>>>>> On Mon, Apr 3, 2017 at 12:56 PM, Thomas Hellstrom >>>>>>>> <thellst...@vmware.com> wrote: >>>>>>>>> Hi, Rob, >>>>>>>>> >>>>>>>>> On 03/24/2017 10:21 PM, Rob Clark wrote: >>>>>>>>>> It's kinda sad that (a) we don't have debug_backtrace support on !X86 >>>>>>>>>> and that (b) we re-invent our own crude backtrace support in the >>>>>>>>>> first >>>>>>>>>> place. If available, use libunwind instead. The backtrace format is >>>>>>>>>> based on what xserver and weston use, since it is nice not to have to >>>>>>>>>> figure out a different format. >>>>>>>>>> >>>>>>>>>> Signed-off-by: Rob Clark <robdcl...@gmail.com> >>>>>>>>> Did you consider glibc "backtrace()", I think it's also available on >>>>>>>>> ARM... >>>>>>>> I had not.. although xserver and weston are already using libunwind. >>>>>>>> I'm not sure about portability of libunwind to other libc >>>>>>>> implementations (but I guess it is at least not worse than using a >>>>>>>> glibc specific API). >>>>>>>> >>>>>>>> I suppose we could always add a fallback to backtrace(). >>>>>>>> >>>>>> Hmm. This commit (bisected) appears to break svga/vmwgfx in DEBUG mode: >>>>>> >>>>>> *** Error in `glxgears': malloc(): memory corruption: 0x00000000025c09c0 >>>>>> *** >>>>>> Aborted (core dumped) >>>>>> >>>>>> The svga linux winsys makes extensive use of the backtrace functionality >>>>>> using u_debug_flush.c >>>>> ok, I can reproduce.. hopefully patch following shortly.. >>>>> >>>> So, I found one other minor issue, but the big problem is >>>> debug_stack_frame size difference, because u_debug_flush.c doesn't >>>> #include config.h.. adding: >>>> >>>> #ifdef HAVE_CONFIG_H >>>> #include <config.h> >>>> #endif >>> Hmm, >>> >>> Actually it seems we don't have a config.h, but rather -DHAVE_LIBUNWIND >>> is included in the compile command. >> >> That's correct. HAVE_CONFIG_H is never defined and the only config.h >> file we have is completely unrelated. Thus I'm not sure how the above >> ifdef hunk helped anyone. >> > > > hmm.. odd.. unless touching the .h file somehow triggered something to > recompile? That was definitely the last change I made before it > stopped crashing. But possibly something got out of whack with > timestamps or something on my end. >
btw, I think I realized what happened. I was using a different device which did not initially have libunwind-devel installed. And I realized that after installing it and re-./configure'ing the next build went rather fast. So I guess until I touched u_debug_stack.h nothing triggered the rest of the .c files that included it to rebuild after -DHAVE_LIBUNWIND was added to the compile line.. BR, -R _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
