Re: Development setup
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tuesday 25 May 2004 23:43, Maurice van der Pot wrote: > The modifications I made to the driver were visible when I executed an > OpenGL app, so I knew it was using the right r200_dri.so. Strangely, > I was unable to get most of the debug prints working. The general ones > with LIBGL_DEBUG seemed to work, but not the r200 specific ones. Look in r200_context.h for DO_DEBUG, and set it to 1. I assume you've already set the environment variable R200_DEBUG, as well. cu, Nicolai -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAtQCKsxPozBga0lwRAitiAJ9opTRg/AbVBlvy6Fq6lyjg5Ji7gACeI9by gqPrSG0hAQi2SdIbn1UFGHQ= =NaxW -END PGP SIGNATURE- --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id149&alloc_id66&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Development setup
Maurice van der Pot wrote: On Mon, May 24, 2004 at 08:54:27AM -0700, Ian Romanick wrote: For a developer, the best bet is to get the DRI tree and the Mesa tree. Build the DRI tree and do a 'make install' as root *once*. The thing is that I didn't want to modify (pollute? ruin?) my working X install and was trying to make things work completely as a normal user. Then just 'cp -a /usr/X11R6 /usr/X11R6.bak'. If you want to revert to your original X setup, 'mv /usr/X11R6 /usr/X11R6.dri ; mv /usr/X11R6.bak /usr/X11R6'. It's important to do the cp the first time because the DRI needs some stuff from an X install. We don't include everything in the source tree. For this I set LIBGL_DRIVERS_DIR to /home/griffon26/cvs-wa/xc/xc/lib/GL/mesa/drivers/dri/r200 and I added /home/griffon26/cvs-wa/xc/xc/lib/GL/GL/ to my LD_LIBRARY_PATH. ldd then told me that my OpenGL app was using the right libGL: libGL.so.1 => /home/griffon26/cvs-wa/xc/xc/lib/GL/GL/libGL.so.1 (0x40014000) That's not right. You should be using a build tree, first off. Secondly, you should point at the exports directory. If you're doing everything in the DRI tree, your LIBGL_DRIVERS_DIR would be .../build/xc/exports/lib/modules/dri. If you think that doing a make install once will change things, then I'll do it. It's worth a try anyway. Although, it sounds like you're getting all the right files anyway. How big is your r200_dri.so? It should be on the order of 17MB (yes, seventeen) if it has debug information. Then do your development in the Mesa tree, build your drivers in the Mesa tree, and run with 'LIBGL_DRIVERS_DIR' set to the lib directory in the Mesa tree (i.e., from the top of the Mesa tree do 'export LIBGL_DRIVERS_DIR=$(pwd)/lib'. But you just said that the libGL in the Mesa tree was not the one to be used? I'm confused why I should do development in the Mesa tree, because the DRI tree has links to the source files in the Mesa tree, so I can modify and build there. All I would ever have to do in the mesa tree is run cvs commands, right? I don't even think I _can_ do a build from the Mesa tree. Okay. There's 3 parts of a 3D driver (excluding the parts that live in the 2D driver). There's the kernel module. That's the DRM stuff, and it lives in the drm module of the DRI project. There's the driver loader. That is part of what libGL does. libGL communicates with the X server (which communicates, via the 2D driver, with the kernel part) to determine which 3D driver to load and to setup some aspects of the hardware. Almost all of the code for libGL lives in xc/xc/lib/GL/glx in the DRI tree. Some of the code for it comes from the Mesa tree. The 3rd part, and the part that is most intersting to most people, is the 3D driver itself. All of the code, except a small library used to communicate with the kernel, lives in the Mesa tree. If you edit the DRM_SOURCE_PATH in configs/default to point to the drm sources (the drm module from the DRI tree mentioned above), you can do 'make linux-dri' in your Mesa tree to build the *_dri.so files. They will end up in the lib directory at the top of the Mesa tree. There are also linux-dri-x86 and linux-dri-x86-64 targets. The advantage is that you're doing all your work in one tree AND the build ends up being faster. In the (hopefully near) future, the DRI tree will contain a stable copy of the Mesa tree. At that time, all driver work (and builds) will happen in the Mesa tree. You really only need to do builds in the DRI tree if you're working on libGL, working on the server-side GLX stuff, or working on the 2D driver. Truth be told, you could just grab a newer libGL.so from one of the nightly snapshots and never get the xc tree at all. I still don't understand why GDB is acting strange. Maybe this is something I have to figure out on my own, because I don't think it's DRI specific. Anyway, here's what happens when I type sharedlibrary after I hit a breakpoint on a glBegin call. (gdb) sharedlibrary Symbols already loaded for /home/griffon26/cvs-wa/xc/xc/lib/GL/GL/libGL.so.1 Symbols already loaded for /usr/lib/libGLU.so.1 Symbols already loaded for /usr/lib/libglut.so.3 [etc etc] Symbols already loaded for /usr/X11R6/lib/libXt.so.6 Reading symbols from /home/griffon26/cvs-wa/xc/xc/lib/GL/mesa/drivers/dri/r200/r200_dri.so...done. Loaded symbols for /home/griffon26/cvs-wa/xc/xc/lib/GL/mesa/drivers/dri/r200/r200_dri.so (gdb) auto-solib-add was already on. I do get this message when I run my program in gdb... maybe that's why warning: Unable to find dynamic linker breakpoint function. GDB will be unable to debug shared library initializers and track explicitly loaded dynamic code. That's really, really weird. Can you give some more details about your system? What distro are you using? glibc version? gdb version? This stuff has worked for me out of the box on every Redhat version from 7.1 through FC1. You might need to ask about th
Re: Development setup
Thanks for your response Ian. On Mon, May 24, 2004 at 08:54:27AM -0700, Ian Romanick wrote: > > How are you building? Are you building everything in the DRI tree? > libGL in the DRI tree and the drivers in the Mesa tree? The libGL built > in the Mesa tree is *NOT* the one used with the DRI drivers. The libGL > built in the DRI tree (or from the DRI binary snapshots) should have all > the debug symbols included. I was building everything from the DRI tree. I noticed that I had to use the libGL in the DRI tree because of the timestamp. > As for r200_dri.so, are you sure it's getting the right one? If you run > with 'LIBGL_DEBUG=verbose' it will print out which driver binary is > being used. The modifications I made to the driver were visible when I executed an OpenGL app, so I knew it was using the right r200_dri.so. Strangely, I was unable to get most of the debug prints working. The general ones with LIBGL_DEBUG seemed to work, but not the r200 specific ones. > For a developer, the best bet is to get the DRI tree and the Mesa tree. > Build the DRI tree and do a 'make install' as root *once*. The thing is that I didn't want to modify (pollute? ruin?) my working X install and was trying to make things work completely as a normal user. For this I set LIBGL_DRIVERS_DIR to /home/griffon26/cvs-wa/xc/xc/lib/GL/mesa/drivers/dri/r200 and I added /home/griffon26/cvs-wa/xc/xc/lib/GL/GL/ to my LD_LIBRARY_PATH. ldd then told me that my OpenGL app was using the right libGL: libGL.so.1 => /home/griffon26/cvs-wa/xc/xc/lib/GL/GL/libGL.so.1 (0x40014000) If you think that doing a make install once will change things, then I'll do it. > Then do > your development in the Mesa tree, build your drivers in the Mesa tree, > and run with 'LIBGL_DRIVERS_DIR' set to the lib directory in the Mesa > tree (i.e., from the top of the Mesa tree do 'export > LIBGL_DRIVERS_DIR=$(pwd)/lib'. But you just said that the libGL in the Mesa tree was not the one to be used? I'm confused why I should do development in the Mesa tree, because the DRI tree has links to the source files in the Mesa tree, so I can modify and build there. All I would ever have to do in the mesa tree is run cvs commands, right? I don't even think I _can_ do a build from the Mesa tree. I still don't understand why GDB is acting strange. Maybe this is something I have to figure out on my own, because I don't think it's DRI specific. Anyway, here's what happens when I type sharedlibrary after I hit a breakpoint on a glBegin call. (gdb) sharedlibrary Symbols already loaded for /home/griffon26/cvs-wa/xc/xc/lib/GL/GL/libGL.so.1 Symbols already loaded for /usr/lib/libGLU.so.1 Symbols already loaded for /usr/lib/libglut.so.3 [etc etc] Symbols already loaded for /usr/X11R6/lib/libXt.so.6 Reading symbols from /home/griffon26/cvs-wa/xc/xc/lib/GL/mesa/drivers/dri/r200/r200_dri.so...done. Loaded symbols for /home/griffon26/cvs-wa/xc/xc/lib/GL/mesa/drivers/dri/r200/r200_dri.so (gdb) auto-solib-add was already on. I do get this message when I run my program in gdb... maybe that's why warning: Unable to find dynamic linker breakpoint function. GDB will be unable to debug shared library initializers and track explicitly loaded dynamic code. Best regards, Maurice. --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Development setup
Maurice van der Pot wrote: I have just started looking into DRI development and I have been experiencing some difficulties using gdb. For example, I cannot currently step into functions of libGL (it was compiled with debug info and LD_LIBRARY_PATH is set correctly). Another thing is that the symbols from r200_dri.so are only loaded after I have typed sharedlibrary r200_dri, they're not loaded automatically when the shared object is loaded even though gdb's option (I forget its name) to autoload symbols is on. How are you building? Are you building everything in the DRI tree? libGL in the DRI tree and the drivers in the Mesa tree? The libGL built in the Mesa tree is *NOT* the one used with the DRI drivers. The libGL built in the DRI tree (or from the DRI binary snapshots) should have all the debug symbols included. As for r200_dri.so, are you sure it's getting the right one? If you run with 'LIBGL_DEBUG=verbose' it will print out which driver binary is being used. Realistically, you *need* two systems for driver debugging. I've found that using a skunky old laptop to ssh in and run gdb is the best setup. In a pinch, an old 286 with a terminal program as a serial terminal will also work. As I was struggling to put together a convenient setup for debugging it got me wondering how those of you who use gdb for debugging have things set up. I'm interested to know things like locations of compiled libs/executables wrt the system libs, environment variables, makefile/config modifications, etc. For a developer, the best bet is to get the DRI tree and the Mesa tree. Build the DRI tree and do a 'make install' as root *once*. Then do your development in the Mesa tree, build your drivers in the Mesa tree, and run with 'LIBGL_DRIVERS_DIR' set to the lib directory in the Mesa tree (i.e., from the top of the Mesa tree do 'export LIBGL_DRIVERS_DIR=$(pwd)/lib'. Maybe I can gather this information into a document on the Wiki later on. Not a bad idea. --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Development setup
Hello, I have just started looking into DRI development and I have been experiencing some difficulties using gdb. For example, I cannot currently step into functions of libGL (it was compiled with debug info and LD_LIBRARY_PATH is set correctly). Another thing is that the symbols from r200_dri.so are only loaded after I have typed sharedlibrary r200_dri, they're not loaded automatically when the shared object is loaded even though gdb's option (I forget its name) to autoload symbols is on. As I was struggling to put together a convenient setup for debugging it got me wondering how those of you who use gdb for debugging have things set up. I'm interested to know things like locations of compiled libs/executables wrt the system libs, environment variables, makefile/config modifications, etc. Maybe I can gather this information into a document on the Wiki later on. Thanks in advance, Maurice van der Pot. --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
