* Problem in debugging GPS @ 2006-09-26 7:24 Sandor Lengyel 2006-09-26 19:25 ` Ludovic Brenta 2006-09-27 13:01 ` Martin Krischik 0 siblings, 2 replies; 9+ messages in thread From: Sandor Lengyel @ 2006-09-26 7:24 UTC (permalink / raw) I modified GPS to work with gcc 4.1.1. using gcc 4.1.1 Now I try to debug it using gdb 6.3 (Ada enabled and ddd) Something funny is happening. In file projects-editor.adb I have the following code segment: function Create_Project (Registry : Projects.Registry.Project_Registry'Class; NameP, Path : String) return Project_Type is D : constant String := Path & To_File_Name (NameP) & Project_File_Extension; Project : Project_Node_Id; Project_Name : Name_Id; P : Project_Type; begin -- Prj.Tree.Initialize (InTree); -- Adding the name of the project Project_Name := Get_String (NameP); Set_Name_Of (Project, InTree, Project_Name); Now Entering Create_Projects and displaying NameP i see that NapmeP is: (gnat.string.string_access) 0x91385cc. Doing Stepi this value stayes even executing: D : constant String := Path & To_File_Name (NameP) & Project_File_Extension; However doing one more Stepi the cursor jumps to P : Project_Type; and NameP value changes to: (gnat.string.string_access) 0xfffffff. The machine code executed is: <projects__editor__create_project+573>: mov 0x8e42944,%ebx This value stayes for the rest of the code. Why? ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Problem in debugging GPS 2006-09-26 7:24 Problem in debugging GPS Sandor Lengyel @ 2006-09-26 19:25 ` Ludovic Brenta 2006-09-27 13:01 ` Martin Krischik 1 sibling, 0 replies; 9+ messages in thread From: Ludovic Brenta @ 2006-09-26 19:25 UTC (permalink / raw) Sandor Lengyel <slengyel@chello.hu> writes: > I modified GPS to work with gcc 4.1.1. using gcc 4.1.1 Me too, and it crashes badly. I compiled with -gstabs+ and at least I get clean stack traces with the old gnat-gdb 5.3. That hasn't helped me find the cause, though. -- Ludovic Brenta. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Problem in debugging GPS 2006-09-26 7:24 Problem in debugging GPS Sandor Lengyel 2006-09-26 19:25 ` Ludovic Brenta @ 2006-09-27 13:01 ` Martin Krischik 2006-09-27 15:51 ` Ludovic Brenta 1 sibling, 1 reply; 9+ messages in thread From: Martin Krischik @ 2006-09-27 13:01 UTC (permalink / raw) Sandor Lengyel schrieb: > I modified GPS to work with gcc 4.1.1. using gcc 4.1.1 Great - I did not get that far. How about joining The GNU Ada Project [1] and share your patches with the rest of us? We alwas welcome new maintainers and if you got the GPS to compile you certainly are our man. Martin [1] http://gnuada.sf.net ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Problem in debugging GPS 2006-09-27 13:01 ` Martin Krischik @ 2006-09-27 15:51 ` Ludovic Brenta 2006-09-27 18:18 ` Martin Krischik 2006-09-28 6:01 ` Simon Wright 0 siblings, 2 replies; 9+ messages in thread From: Ludovic Brenta @ 2006-09-27 15:51 UTC (permalink / raw) Martin Krischik <krischik@users.sourceforge.net> writes: >> I modified GPS to work with gcc 4.1.1. using gcc 4.1.1 > > Great - I did not get that far. How about joining The GNU Ada > Project [1] and share your patches with the rest of us? We alwas > welcome new maintainers and if you got the GPS to compile you > certainly are our man. > > Martin > > [1] http://gnuada.sf.net If you like, I can send you my changes. I've not only added a patch to the GPS sources themselves, but I've also rewritten the build machinery in a drastically simplistic way, consisting of *one* Makefile (the famous debian/rules) and *one* GNAT project file. This comes at the expense of some flexibility; these scripts are designed to work on Debian and only on Debian. I also make heavy use of shared libraries. My GPS uses not only libgtkada.so.2.8.1, but also libtemplates_parser.so.10, libgnatvsn.so.4.1, libgnatprj.so.4.1, and libpython2.4.so.1 (yes, Python is enabled in the Debian build, even in GPS 2.1.0). Thus, I completely avoid the code duplication that AdaCore seem so fond of. Even then, it takes 2h40 to compile GPS on my laptop, compared to 1 hour for GPS 2.1.0. Part of the increase comes from GPS itself, and part from the compiler, as GCC 4.1.1 is noticeably slower and more memory-hungry than GNAT 3.15p. The patches, on the other hand, are not specific to Debian, so you could try them if you like. They apply cleanly on the pristine sources for GPS 4.0.0, and are managed with quilt. It is also very easy to apply them manually if you just read the short file, patches/series. The patch "gcc-4.1.patch" in which you are interested is a mere 269 lines long. The down side is that, as I said, GPS crashes when it opens a "file open" dialog. The problem looks like a stack overflow in GTK+, but I'm not sure. I recompiled with -O0 but got the same results. -O0 -fstack-check fared no better. I still don't know if it's a compiler bug or a GPS bug. Since testgtk works correctly, I don't think it is a GtkAda or GTK+ bug. You can get the Debian scripts and patches from my Monotone server on Ada-France, if you want. The reasons why I did not join the GNU Ada project on SourceForge are because (a) I dislike Subversion, (b) the Debian patches are older and much more extensive than the ones you have, and (c) the build machineries mandated by the package managers (RPM vs. DPKG) are radically different; so, merging the Debian patches and GNU Ada would be quite a lot of work. I'm not against it, though. -- Ludovic Brenta. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Problem in debugging GPS 2006-09-27 15:51 ` Ludovic Brenta @ 2006-09-27 18:18 ` Martin Krischik 2006-09-27 19:15 ` Ludovic Brenta 2006-09-28 6:01 ` Simon Wright 1 sibling, 1 reply; 9+ messages in thread From: Martin Krischik @ 2006-09-27 18:18 UTC (permalink / raw) Ludovic Brenta wrote: > Martin Krischik <krischik@users.sourceforge.net> writes: >>> I modified GPS to work with gcc 4.1.1. using gcc 4.1.1 >> >> Great - I did not get that far. How about joining The GNU Ada >> Project [1] and share your patches with the rest of us? We alwas >> welcome new maintainers and if you got the GPS to compile you >> certainly are our man. >> >> Martin >> >> [1] http://gnuada.sf.net > > If you like, I can send you my changes. I've not only added a patch > to the GPS sources themselves, but I've also rewritten the build > machinery in a drastically simplistic way, consisting of *one* > Makefile (the famous debian/rules) and *one* GNAT project file. This > comes at the expense of some flexibility; these scripts are designed > to work on Debian and only on Debian. But they are probably easier to read the en automake/autoconf stuff. > I also make heavy use of shared libraries. My GPS uses not only > libgtkada.so.2.8.1, but also libtemplates_parser.so.10, > libgnatvsn.so.4.1, libgnatprj.so.4.1, and libpython2.4.so.1 (yes, > Python is enabled in the Debian build, even in GPS 2.1.0). Thus, I > completely avoid the code duplication that AdaCore seem so fond of. I never understood that. And am always nagged AdaCore about it. But they allways mandated that is has to be that way and it would not work any other way... Anyway: I would not mind adding similar libs to the R7 distribution (which is currently not in planning ;-) ). > The patches, on the other hand, are not specific to Debian, so you > could try them if you like. They apply cleanly on the pristine > sources for GPS 4.0.0, and are managed with quilt. It is also very > easy to apply them manually if you just read the short file, > patches/series. The patch "gcc-4.1.patch" in which you are interested > is a mere 269 lines long. A mere 269 lines.... > The down side is that, as I said, GPS crashes when it opens a "file > open" dialog. The problem looks like a stack overflow in GTK+, but > I'm not sure. I recompiled with -O0 but got the same results. -O0 > -fstack-check fared no better. I still don't know if it's a compiler > bug or a GPS bug. Since testgtk works correctly, I don't think it is > a GtkAda or GTK+ bug. Up until I deleted my .gkt* and .gnome files any GTK+ application started by root crashed. Before you ask: vim is gtk+. For my main user user Gtk+ applications crash when opening a menu. But only when they where started from an icon. They work fine when started from an terminal window. ?!?! And if I start gnome-control-center beforehand the applications look all different as when I don't. Mind you I use KDE as desktop. But then: KDE applications never make such a fuss - even when started under a GNOME desktop. It is just that Gtk/GNOME is such a "Mimose" as we would say in Germany (Mimose: a flower which dies quickly when not treated to absolute perfection). > You can get the Debian scripts and patches from my Monotone server on > Ada-France, if you want. The reasons why I did not join the GNU Ada > project on SourceForge are because (a) I dislike Subversion, (b) the > Debian patches are older and much more extensive than the ones you > have, and (c) the build machineries mandated by the package managers > (RPM vs. DPKG) are radically different; so, merging the Debian patches > and GNU Ada would be quite a lot of work. I'm not against it, though. Ok for (a) and (b) - but for (c): RPM is just one option. The Solaris maintainer create tar-balls. For MinGW I too have tried tar-balls and I have created quite a well working RPM-Spec to Tarball-Bash converter. Only MinGW on its own does not compile at all. Even Arno mentioned once that AdaCore uses cygwin for automake/autoconf etc.pp. So my current hopes are on an MinGW/Cygwin combo for MS-Windows. Martin -- mailto://krischik@users.sourceforge.net Ada programming at: http://ada.krischik.com ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Problem in debugging GPS 2006-09-27 18:18 ` Martin Krischik @ 2006-09-27 19:15 ` Ludovic Brenta 2006-09-28 7:02 ` Martin Krischik 0 siblings, 1 reply; 9+ messages in thread From: Ludovic Brenta @ 2006-09-27 19:15 UTC (permalink / raw) Martin Krischik <krischik@users.sourceforge.net> writes: >> If you like, I can send you my changes. I've not only added a patch >> to the GPS sources themselves, but I've also rewritten the build >> machinery in a drastically simplistic way, consisting of *one* >> Makefile (the famous debian/rules) and *one* GNAT project file. This >> comes at the expense of some flexibility; these scripts are designed >> to work on Debian and only on Debian. > > But they are probably easier to read the en automake/autoconf stuff. Oh yes, by a wide margin. They're also much less brittle and sensitive to the installed versions of the autotools. In fact, they are not sentitive at all to the autotools, since they don't use them. In GPS, I haven't been able to avoid building some parts of SourceNavigator and Berkeley DB, which are both bundled in the upstream tarball. For these I still have to call configure and a recursive make. >> I also make heavy use of shared libraries. My GPS uses not only >> libgtkada.so.2.8.1, but also libtemplates_parser.so.10, >> libgnatvsn.so.4.1, libgnatprj.so.4.1, and libpython2.4.so.1 (yes, >> Python is enabled in the Debian build, even in GPS 2.1.0). Thus, I >> completely avoid the code duplication that AdaCore seem so fond of. > > I never understood that. And am always nagged AdaCore about it. But they > allways mandated that is has to be that way and it would not work any other > way... Unfortunately, they seem to be correct as far as 4.0.0 is concerned. 2.1.0 works fine with my simple build scripts and no code duplication, though. Currently, I'm trying to port GPS 3.1.3 forward to using GtkAda 2.8.1. You can already see my unfinished work in the Monotone database, under the branch org.debian.gnat-gps.3.1.3. The branch org.debian.gnat-gps contains the completedstuff for 4.0.0; maybe you or someone else could try and replicate the crash I experience? > Up until I deleted my .gkt* and .gnome files any GTK+ application started by > root crashed. Before you ask: vim is gtk+. I never start applications as root. Except for apt-get and aptitude :) > For my main user user Gtk+ applications crash when opening a menu. But only > when they where started from an icon. They work fine when started from an > terminal window. ?!?! > > And if I start gnome-control-center beforehand the applications look all > different as when I don't. > > Mind you I use KDE as desktop. But then: KDE applications never make such a > fuss - even when started under a GNOME desktop. It is just that Gtk/GNOME > is such a "Mimose" as we would say in Germany (Mimose: a flower which dies > quickly when not treated to absolute perfection). I use IceWM as my window manager. No gnome, no KDE. I occasionally use GTK+ applications (Galeon, GPS, The GIMP) but most often, just emacs and xterm. At one point, for weeks on end I even ran with no X at all; just emacs in full-screen text mode. I stopped doing that when I had to test GPS :) >> You can get the Debian scripts and patches from my Monotone server on >> Ada-France, if you want. The reasons why I did not join the GNU Ada >> project on SourceForge are because (a) I dislike Subversion, (b) the >> Debian patches are older and much more extensive than the ones you >> have, and (c) the build machineries mandated by the package managers >> (RPM vs. DPKG) are radically different; so, merging the Debian patches >> and GNU Ada would be quite a lot of work. I'm not against it, though. > > Ok for (a) and (b) - but for (c): RPM is just one option. The Solaris > maintainer create tar-balls. For MinGW I too have tried tar-balls and I > have created quite a well working RPM-Spec to Tarball-Bash converter. Only > MinGW on its own does not compile at all. Even Arno mentioned once that > AdaCore uses cygwin for automake/autoconf etc.pp. So my current hopes are > on an MinGW/Cygwin combo for MS-Windows. I've standardised the way I make my Debian packages, especially GPS, into two directories: debian/ and patches/. It would be quite easy for you to use patches/; but less easy to use debian/. If you would like to replicate all of that into your Subversion repo, be my guest :) -- Ludovic Brenta. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Problem in debugging GPS 2006-09-27 19:15 ` Ludovic Brenta @ 2006-09-28 7:02 ` Martin Krischik 0 siblings, 0 replies; 9+ messages in thread From: Martin Krischik @ 2006-09-28 7:02 UTC (permalink / raw) Ludovic Brenta schrieb: >> Up until I deleted my .gkt* and .gnome files any GTK+ application started by >> root crashed. Before you ask: vim is gtk+. > > I never start applications as root. Except for apt-get and aptitude :) Interesting - how do you edit your configuration files then? Do you "setfacl -m user:xxx:rwX" on /etc? ;-) Martin ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Problem in debugging GPS 2006-09-27 15:51 ` Ludovic Brenta 2006-09-27 18:18 ` Martin Krischik @ 2006-09-28 6:01 ` Simon Wright 2006-09-28 10:53 ` Code duplication and component-based distributions (was: Problem in debugging GPS) Ludovic Brenta 1 sibling, 1 reply; 9+ messages in thread From: Simon Wright @ 2006-09-28 6:01 UTC (permalink / raw) Ludovic Brenta <ludovic@ludovic-brenta.org> writes: > Thus, I completely avoid the code duplication that AdaCore seem so > fond of. Just for interest -- do you mean object code duplication (ie, place the package's source code on the compiler's search path and recompile it for each project)? As a provider of components who doesn't care what OS the users have to cope with I find this a very natural way to deal! ^ permalink raw reply [flat|nested] 9+ messages in thread
* Code duplication and component-based distributions (was: Problem in debugging GPS) 2006-09-28 6:01 ` Simon Wright @ 2006-09-28 10:53 ` Ludovic Brenta 0 siblings, 0 replies; 9+ messages in thread From: Ludovic Brenta @ 2006-09-28 10:53 UTC (permalink / raw) Simon Wright wrote: > Ludovic Brenta <ludovic@ludovic-brenta.org> writes: > > > Thus, I completely avoid the code duplication that AdaCore seem so > > fond of. > > Just for interest -- do you mean object code duplication (ie, place > the package's source code on the compiler's search path and recompile > it for each project)? No, I meant that I avoid both source and object code duplication. I myself benefit by not having to recompile e.g. GtkAda when I compile GPS. That alone shaves one hour off of a full build on my laptop (thanks to my lean-and-mean build scripts, I hardly ever need a full rebuild anyway). Since the -dev packages for libraries provide the source files, I've removed the duplicated sources from all of my .orig.tar.gz files. For example, I've removed the templates_parser sources from AWS and GPS, and I've removed the bundled parts of GNAT from ASIS and GPS. As for the object code, the read-only ALI files in the -dev package ensure that any package that build-depends on the -dev package will not rebuild the library from source. Then, the run-time library package provides a shared library; all packages that depend on that object code just link with the shared library. For example, both gnat-gps and libaws.so.2.2 link with libtemplates_parser.so.10, and libasis.so.2005 and gnat-gps link against libgnatvsn.so.4.1. I took that approach to such extremes that I even created new libraries that AdaCore thought impossible, or at least very difficult, to make; namely libgnatvsn and libgnatprj. The GNAT tools (gnatmake and friends) and ASIS have been using these libraries for a year now without any problems, thank you very much. And the size of the GNAT tools went down by 90%. Similarly, since the duplicated templates_parsers in AWS and GPS were different and incompatible at the source level, I created a separate package that is compatible with both, by doing a checkout from CVS and then patching further. That package is now in Etch, by the way. All of that is dangerous; don't do it at home if you want a stable system :) the danger is that I may break programs. Right now I'm stuck on GPS because it crashes. I'm starting to get worried by the looming freeze in Etch, and the transition to GCC 4.1 is not yet finished. I think I've been too reliant on the "if it compiles, it will probably work" attitude. This does not hold with GPS, unfortunately, since it compiles but does not work. > As a provider of components who doesn't care what OS the users have to > cope with I find this a very natural way to deal! In theory, yes, but this means you've got to be very good at configuration management (i.e. the use-relationships between the components), and at package management (i.e. installing and upgrading all packages on the platform in a way that is consistent with the desired configuration). On OSs that do not provide good package management, like the one from the Redmond, you're in for trouble. I think that that's why AdaCore prefer code duplication to proper configuration and package management. In those that do provide good package management, you've got to think in terms of the whole system, and how each single component fits in. That also requires good advance planning, and may require lock-step development (i.e. while developing program P, you must wait for library L to be formally released before you can use the new features in it; that precludes truly parallel development of P and L). So, good configuration management and good package management require dedicated work and manpower. I think it is interesting to contrast Gentoo or FreeBSD with Debian. Gentoo and FreeBSD avoid binary compatibility issues by only distributing source packages, and doing automatic builds as part of the installation process. Debian takes the opposite and difficult route: it provides prebuilt binary packages, and so the maintainers have to take binary compatibility into account. Also, Gentoo seems to favour completeness over consistency; they provide several versions of GNAT (both GPL Edition and from the FSF) and let the user decide which one they would prefer. They don't seem to have a very strong policy as regards configuration management; they let their users do that for themselves, with help from the package manager. The GNU Ada Project seems to take the same route. In Debian, again I take the opposite and difficult route favouring consistency over completeness: I provide only one version of GNAT (namely GCC 4.1) but make sure everything works together. -- Ludovic Brenta. ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2006-09-28 10:53 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2006-09-26 7:24 Problem in debugging GPS Sandor Lengyel 2006-09-26 19:25 ` Ludovic Brenta 2006-09-27 13:01 ` Martin Krischik 2006-09-27 15:51 ` Ludovic Brenta 2006-09-27 18:18 ` Martin Krischik 2006-09-27 19:15 ` Ludovic Brenta 2006-09-28 7:02 ` Martin Krischik 2006-09-28 6:01 ` Simon Wright 2006-09-28 10:53 ` Code duplication and component-based distributions (was: Problem in debugging GPS) Ludovic Brenta
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox