X-Authentication-Warning: delorie.com: mail set sender to djgpp-workers-bounces using -f From: Andris Pavenis To: djgpp-workers AT delorie DOT com Subject: Re: Patches to build GDB 6.3 Date: Fri, 10 Dec 2004 15:34:46 +0200 User-Agent: KMail/1.7.2 References: <01c4c987$Blat.v2.2.2$52b9e920 AT zahav DOT net DOT il> <200412101102 DOT 21274 DOT pavenis AT latnet DOT lv> <01c4deb6$Blat.v2.2.2$b539e160 AT zahav DOT net DOT il> In-Reply-To: <01c4deb6$Blat.v2.2.2$b539e160@zahav.net.il> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200412101534.46509.pavenis@latnet.lv> X-Virus-Scanned: by amavisd-new at fgi.fi Reply-To: djgpp-workers AT delorie DOT com On Friday 10 December 2004 14:48, Eli Zaretskii wrote: > > From: Andris Pavenis > > Date: Fri, 10 Dec 2004 11:02:21 +0200 > > > > Register numbering used for call frame was different from one used by > > debugger. So it's also for C. However it perhaps causes runtime problem > > only with C++ exceptions. > > That might be an explanation why I never saw the breakage. > > Can you post a short explaination what is special about C++ exceptions > that reveals the problem only there? Do C++ exceptions use some > special registers that are unused anywhere else? Unwinding stack frame when throwing C++ exception requires a way how to get correct status for caller procedure or catch block. So some description how to get correct values of registers there is needed. This unwind information is also generated when debug information is not (of course one can disable it with -fno-exceptions). Register numbering for stack unwinding does not need to be same as one used for debug information. At least our bad experience shows, that changing register numbering there didn't cause noticable problems. Of course changing it causes object files to be incompatible. > > Also it breaks backtrace command in new versions of GDB for all > > languages. GDB-6.1.1 and earlier versions seemed to work > > OK. GDB-6.2 and higher - no more. > > That's probably because the GDB numbering for BP and SP was changed at > some point between 6.1.1 and 6.2. That change was done for all x86 > targets, including Cygwin and DJGPP. I agreed to that change only > after someone posted a test program an a GDB session transcript to the > GDB mailing list that clearly show that the previous numbering was in > error, and I was able to reproduce the problem on my machine with the > DJGPP port of GDB. So that change was in the right direction; we > should not undo it. Maybe the tests were done with executables compiled with gcc-2.95.3. > > Let me know if you need help digging up that discussion and testing > the code in there with your suggested renumbering. > > > Register numbering used for DWARF2 debugging information was Ok. > > This sentence confused me: are the problems we have been discussing > present only in non-DWARF2 debug info? Or are you saying that the > register numbering in the compiler output was correct, but GDB 6.2 and > later interpreted it incorrectly? No. As I mentioned the problem is in DJGPP port of GCC, but not in GDB. I had about 2-3 years ago problems with C++ exceptions when DWARF2 debugging information were requested. There were some e-mail exchange with Mark Elbrecht, who implemented DWARF2 support in DJGPP port of binutils. So tried to solve these problems, got some working (I thought so that time) solution and left it in djgpp.h with comment, that I don't know whether is's correct. Now I see, that it was not. > Sigh. I guess we will need to change something in an incompatible > way, and we will need to find the best way to do that. What were our > options again? 1) We could wait for gcc-4.0.0 and fix problem there. In that case gdb-6.2 and newers will not work correctly with DJGPP ports of gcc-3.X 2) I could rebuild fixed gcc-3.4.3. In that place we should require at least all C++ sources to be rebuilt (Better all to avoid breakage of GDB backtrace command). Maybe also gcc-3.3.5 should be rebuilt (the same requirements) Andris