mesa3d-dev

[Mesa3d-dev] Debugging OSmesa16

[J.P. D. <jpd...@cs...>]

Hi,

I've started experimenting with the OSmesa16 library on linux and wrote
a simple program based on osdemo16 that draws a single smooth shaded
triangle. I've managed to import the off-screen 16-bit data into Matlab
to do some checks. The program works fine without
glEnable(GL_SMOOTH_POLYGON), but with it gives a garbled triangle. I
would like to familiarise myself with the OSmesa16 code and trace the
origin of the error, but I need some pointers on debugging the lib. I'm
using ddd with gdb and when setting breakpoints e.g. in
swrast/s_triangle.c gdb complains:
Error in re-setting breakpoint 1:
No source file named swrast/s_triangle.c.

I've tried using the gdb dir command to add source search dirs with no
success.

gdb> info shar gives:
From        To          Syms Read   Shared Object Library
0x40015000  0x4002fe30  Yes         /home/jpdelport/Mesa/lib/libGLU.so.1
0x40030000  0x40388fc4  Yes        
/home/jpdelport/Mesa/lib/libOSMesa16.so.1
0x4038e000  0x403aa9d8  Yes         /lib/libm.so.6
0x403ab000  0x403bd138  Yes         /lib/libpthread.so.0
0x403bf000  0x404b385c  Yes         /lib/libc.so.6
0x40000000  0x40013ed0  Yes         /lib/ld-linux.so.2

I compiled (from a CVS checkout on 28/05) libOSMesa16 with: make -f
Makefile.X11 linux-osmesa16
and compiled libGLU by going to src-glu and doing: make -f Makefile.X11
linux-debug

Any pointers to what I'm doing wrong or how I'm supposed to set up an
OSmesa debugging session would be appreciated.

thanks
jp

Re: [Mesa3d-dev] Debugging OSmesa16

[Brian P. <br...@va...>]

"J.P. Delport" wrote:
> 
> Hi,
> 
> I've started experimenting with the OSmesa16 library on linux and wrote
> a simple program based on osdemo16 that draws a single smooth shaded
> triangle. I've managed to import the off-screen 16-bit data into Matlab
> to do some checks. The program works fine without
> glEnable(GL_SMOOTH_POLYGON), but with it gives a garbled triangle.

I'll look into this.


> I
> would like to familiarise myself with the OSmesa16 code and trace the
> origin of the error, but I need some pointers on debugging the lib. I'm
> using ddd with gdb and when setting breakpoints e.g. in
> swrast/s_triangle.c gdb complains:
> Error in re-setting breakpoint 1:
> No source file named swrast/s_triangle.c.
> 
> I've tried using the gdb dir command to add source search dirs with no
> success.
> 
> gdb> info shar gives:
> >From        To          Syms Read   Shared Object Library
> 0x40015000  0x4002fe30  Yes         /home/jpdelport/Mesa/lib/libGLU.so.1
> 0x40030000  0x40388fc4  Yes
> /home/jpdelport/Mesa/lib/libOSMesa16.so.1
> 0x4038e000  0x403aa9d8  Yes         /lib/libm.so.6
> 0x403ab000  0x403bd138  Yes         /lib/libpthread.so.0
> 0x403bf000  0x404b385c  Yes         /lib/libc.so.6
> 0x40000000  0x40013ed0  Yes         /lib/ld-linux.so.2
> 
> I compiled (from a CVS checkout on 28/05) libOSMesa16 with: make -f
> Makefile.X11 linux-osmesa16
> and compiled libGLU by going to src-glu and doing: make -f Makefile.X11
> linux-debug
> 
> Any pointers to what I'm doing wrong or how I'm supposed to set up an
> OSmesa debugging session would be appreciated.

First, be sure to recompile the sources with -g and without -O.  Edit
Make-config, look for 'linux-osmesa16'.

If you're debugging a dynamic library you can't set breakpoints in the
library code until execution has begun.  Try setting a breakpoint in
main(), run to that point, then set a breakpoint in the Mesa function
you're interested in.

-Brian

Re: [Mesa3d-dev] Debugging OSmesa16

[J.P. D. <jpd...@cs...>]

The garbled triangle is fixed if I change GLubyte to GLchan in
s_aatritemp.h (around line 68) like so:

#ifdef DO_RGBA
   GLfloat rPlane[4], gPlane[4], bPlane[4], aPlane[4];
   DEFMARRAY(GLchan, rgba, MAX_WIDTH, 4);  /* mac 32k limitation */
#endif

I don't know if this is completely right as I'm still learning the code.
Thanks for the debugging tips, I can step around now.

cheers
jp

Brian Paul wrote:
> 
> "J.P. Delport" wrote:
> >
> > Hi,
> >
> > I've started experimenting with the OSmesa16 library on linux and wrote
> > a simple program based on osdemo16 that draws a single smooth shaded
> > triangle. I've managed to import the off-screen 16-bit data into Matlab
> > to do some checks. The program works fine without
> > glEnable(GL_SMOOTH_POLYGON), but with it gives a garbled triangle.
> 
> I'll look into this.
> 
> > I
> > would like to familiarise myself with the OSmesa16 code and trace the
> > origin of the error, but I need some pointers on debugging the lib. I'm
> > using ddd with gdb and when setting breakpoints e.g. in
> > swrast/s_triangle.c gdb complains:
> > Error in re-setting breakpoint 1:
> > No source file named swrast/s_triangle.c.
> >
> > I've tried using the gdb dir command to add source search dirs with no
> > success.
> >
> > gdb> info shar gives:
> > >From        To          Syms Read   Shared Object Library
> > 0x40015000  0x4002fe30  Yes         /home/jpdelport/Mesa/lib/libGLU.so.1
> > 0x40030000  0x40388fc4  Yes
> > /home/jpdelport/Mesa/lib/libOSMesa16.so.1
> > 0x4038e000  0x403aa9d8  Yes         /lib/libm.so.6
> > 0x403ab000  0x403bd138  Yes         /lib/libpthread.so.0
> > 0x403bf000  0x404b385c  Yes         /lib/libc.so.6
> > 0x40000000  0x40013ed0  Yes         /lib/ld-linux.so.2
> >
> > I compiled (from a CVS checkout on 28/05) libOSMesa16 with: make -f
> > Makefile.X11 linux-osmesa16
> > and compiled libGLU by going to src-glu and doing: make -f Makefile.X11
> > linux-debug
> >
> > Any pointers to what I'm doing wrong or how I'm supposed to set up an
> > OSmesa debugging session would be appreciated.
> 
> First, be sure to recompile the sources with -g and without -O.  Edit
> Make-config, look for 'linux-osmesa16'.
> 
> If you're debugging a dynamic library you can't set breakpoints in the
> library code until execution has begun.  Try setting a breakpoint in
> main(), run to that point, then set a breakpoint in the Mesa function
> you're interested in.
> 
> -Brian

Re: [Mesa3d-dev] Debugging OSmesa16

[Brian P. <br...@va...>]

"J.P. Delport" wrote:
> 
> The garbled triangle is fixed if I change GLubyte to GLchan in
> s_aatritemp.h (around line 68) like so:
> 
> #ifdef DO_RGBA
>    GLfloat rPlane[4], gPlane[4], bPlane[4], aPlane[4];
>    DEFMARRAY(GLchan, rgba, MAX_WIDTH, 4);  /* mac 32k limitation */
> #endif
>
> I don't know if this is completely right as I'm still learning the code.
> Thanks for the debugging tips, I can step around now.

Yup, that'll do it.  I think we were using GLchan before I applied
that Macintosh patch.  I'll check in the fix ASAP.

-Brian