Version: (using KDE Devel) Installed from: Compiled sources I can hear the groans now... Gideon needs it's own tree of the normal libraries built with debug symbols and an easy way to add less standard ones to the tree. It's more than a little annoying to create your first project from the wizard and have it wander off into nowhere when you try to figure out just what is complaining about not being able to load a library. (The "out-of-the-box" behaviour of both old and new kdevelop versions is a separate bug, but basically you should be able to install on a new system and not do anything in order to build and walk through a wizard created project.) P.S. When I'm in user mode I'm an obnoxious SOB.
Let me get this straigt, what you want is: When you install KDevelop, automaticaly recompile _ALL_ libraries of your entire system so that when you debug a piece of code you made (and uses a couple of system libraries) and the debugger finds all symbols? Is that what you want?
Subject: Re: debug versions of libraries Amilcar do Carmo Lucas wrote: >------- You are receiving this mail because: ------- >You reported the bug, or are watching the reporter. > >http://bugs.kde.org/show_bug.cgi?id=60005 >a.lucas@tu-bs.de changed: > > What |Removed |Added >---------------------------------------------------------------------------- > Version|unspecified |CVS > > > >------- Additional Comments From a.lucas@tu-bs.de 2003-06-19 10:41 ------- >Let me get this straigt, what you want is: >When you install KDevelop, automaticaly recompile _ALL_ libraries of your >entire system so that when you debug a piece of code you made (and uses a >couple of system libraries) and the debugger finds all symbols? > >Is that what you want? > > > I'd want that as an option. Of course, the libraries would have to be in their own lib trees so as to not bring the system to a crawl. It would be better to just have all the symbols in a separate database, but I don't think unix works that way. What I want is to be able to walk into any piece of code the application uses while in the debugger. If there's some other way of doing this that would be fine. Sphere.
I hope you understand that AFAIK you need to recompile your entire system with -g3. That includes Kernel, XFree, QT, KDE and so on ..... And you want all that by cliking an option?
(Why am I only getting some messages in my mailbox? I'm not on any of your mailing lists yet; which might be why. Anyway, knowing that someone asked me a question is a bit hard to determine...) Microsloth releases a browser database for their MFC with the IDE. Debugging chokes if you try to enter the kernel, but you can go a lot deeper with VC++ can you can here. Rebuilding on clicking an option had better do the work in batch. ;) As far as debugging into the kernel, I doubt unix is smart enough to handle doing that correctly. I've only ever used one operating system smart enough to actually give you a virtual machine. Sphere.
You cannot debug into kernel mode unless the kernel allows you to. No sane kernel allows a normal debug operation to do that -- especially because that would halt the kernel itself. As for debugging into the system libraries, the solution is quite simple: rebuild them yourself with debugging symbols. KDevelop cannot possibly contain the debugging symbols for the libraries that are already installed in your system -- only you or your distributor can. Of course, debugging into those libraries requires having their source code installed as well, but if you've rebuilt them, it's not a problem. I sincerely hope we've misunderstood your request and that you're not asking for KDevelop to include the source code and debugging versions of all system libraries. One does not have to debug into printf(3) or open(2) to know what they do.
You can keep a bunch of debug libraries in a special dir and adjust the LD path to point to them for debugging. You can use rpath for example, to force linking to those. Anyways, this is on OS/Build system level, please bug the people who thought of that way, KDevelop is an IDE and supports any build system.
Subject: Re: debug versions of libraries Harald Fernengel wrote: >------- You are receiving this mail because: ------- >You reported the bug, or are watching the reporter. > >http://bugs.kde.org/show_bug.cgi?id=60005 >harry@kdevelop.org changed: > > What |Removed |Added >---------------------------------------------------------------------------- > Status|UNCONFIRMED |RESOLVED > Resolution| |INVALID > > > >------- Additional Comments From harry@kdevelop.org 2003-06-19 19:03 ------- >You can keep a bunch of debug libraries in a special dir and adjust the LD path to point to >them for debugging. You can use rpath for example, to force linking to those. > >Anyways, this is on OS/Build system level, please bug the people who thought of that way, >KDevelop is an IDE and supports any build system. > > > I doubt that.
Subject: Re: debug versions of libraries Thiago Macieira wrote: >------- You are receiving this mail because: ------- >You reported the bug, or are watching the reporter. > >http://bugs.kde.org/show_bug.cgi?id=60005 > > > > >------- Additional Comments From thiagom@mail.com 2003-06-19 18:43 ------- >You cannot debug into kernel mode unless the kernel allows you to. No sane >kernel allows a normal debug operation to do that -- especially because that >would halt the kernel itself. > ... A sane kernel would keep itself completely protected in its' own virtual machine you couldn't get at and would present you with a virtual machine which looked like you had complete freedom to do what you wanted. All the real kernel would do is context switching. mapping of virtual hardware to real hardware, and provide some narrow form of message passing between virtual machines in order to allow bootstrapping and hardware allocation. (Yes, I've used an OS which worked that way. It was a great system for writing standalone code on. You could write the code in a timeshared environment and actually have it work when you ported it to an empty machine. Yes, you could bring up an instance of the OS in a virtual machine and it would think it had a real machine to run on -- if a bit slowly, and usually with fewer devices.)
What you are seaching for is called User Mode Linux, and can be found here: http://user-mode-linux.sourceforge.net/ I'm not sure why you want to debug into the kernel though, unless you were writing kernel-level code or code directly accessing kernel space. As to the creating debug versions of libraries, check out http://women.kde.org/projects/coding/kde2+3.phtml - this should give you an idea on how to set up a development environment for qt and kde. I don't understand the logic of trying to develop your application on a production system/environment to start with. As you will discover the more you look around, linux has an excellent array of debugging tools available; one I particularly recommend is valgrind http://developer.kde.org/~sewardj/
Subject: Re: debug versions of libraries Hamish Rodda wrote: >What you are seaching for is called User Mode Linux, and can be found here: >http://user-mode-linux.sourceforge.net/ I'm not sure why you want to debug >into the kernel though, unless you were writing kernel-level code or code >directly accessing kernel space. > Neat! I may look into that someday if I ever have a real need. Thanks. > >As to the creating debug versions of libraries, check out >http://women.kde.org/projects/coding/kde2+3.phtml - this should give you an >idea on how to set up a development environment for qt and kde. I don't >understand the logic of trying to develop your application on a production >system/environment to start with. > The logic is being in the field and having no other choice. I'll put women.kde.org on my TODO list. > >As you will discover the more you look around, linux has an excellent array of >debugging tools available; one I particularly recommend is valgrind >http://developer.kde.org/~sewardj/ > > > It has a large array, but not an excellent one. I don't like anything else about Windoze, but I do like VC++. That's your competition. If you can't beat it then moving Windoze programmers to Linux will continue to be pulling teeth. If you can beat it then Windoze will die within five years. There are limits to management's (and even the customers') control over the matter. Sphere.