X-Spam-Check-By: sourceware.org From: "Dave Korn" To: Subject: Cygwin, gdb and SEH [was RE: 1.5.19: changes have broken Qt3] Date: Wed, 24 May 2006 19:06:32 +0100 Message-ID: <052c01c67f5c$c9dab430$a501a8c0@CAM.ARTIMI.COM> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <44748613.9000005@freenet.de> Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com On 24 May 2006 17:13, Ralf Habacker wrote: > Brian Dessent schrieb: >> Ralf Habacker wrote: >> >> And yes, it used to be that gdb was too dumb to recognise that these >> faults in IsBadReadPtr were not actual faults, and it would print them >> as spurious SIGSEGVs, just as it currently does for "myfault"s. Then it >> was patched to ignore faults in kernel32.dll. Now that the handler is >> in cygwin1.dll, it had to be taught to ignore faults there too, and if >> you use a CVS GDB, it does. > > This kind of exceptions are handled complete in cygwin itself. Is there > no way to limit this exceptions to the cygwin library itself and to hide > them to the rest ? I'm going to have to start shouting now, because you clearly can't hear or aren't listening to anything that's being said. YES, THERE IS A WAY! WHAT IS MORE YOU HAVE ALREADY HAD IT EXPLAINED TO YOU A DOZEN TIMES IN THIS THREAD! THE WAY IS TO USE AN UP-TO-DATE GDB! You have everything back to front. The problem is not for cygwin to hide these exceptions from gdb; the problem is for gdb not to jump in ahead of cygwin and intercept them. *That* is why fixing gdb is the right thing. > This way exceptions are handled looks to me like a specific > implementation detail, which will worry users more than that it helps to > find problems in an application. Yes, that is why GDB has been patched. However, there is no way on earth that an old out-of-date gdb could know about some trick that was only introduced into the cygwin source years later. We aim for backward compatibility, forward is trickier. > You may say to, this has to be done by gdb, but what about strace ? Do I > need to run strace through gdb to avoid such exception messages ? Or > will strace be patched too to hide such messages ? Learn to use "grep -v" or RTFM about the --mask option to strace. The fact that *you* do not want to see these messages does not mean they are not useful for others. > Remember the previously listed examples where those messages occupies > about 70% of the whole output of an straced application. If you attempt to misuse strace as a tool for debugging your applications, you will run into this kind of problem, and it will be your fault. RTFM: http://cygwin.com/cygwin-ug-net/using-utils.html#strace quite clearly states "This program is mainly useful for debugging the Cygwin DLL itself." > Because this exception addresses are located in the cygwin dll it will > produce many, many obsolate support requests to the cygwin mailing list > (as I was faced) See, this is the *real* problem: you read an obscure internal debugging message emitted by what is effectively a kernel debugging tool, but then you just guessed at what it signified, instead of finding out. The leap to the false conclusion was yours. > and will stresses the support people instead that they LOL! What support people? There are none. > can give support for the real problems and will eat time from the > developer. You appear to be under the same misunderstanding as the guy from yesterday who thought cygwin might have a use for "market research". There is no company, no support team, and any developers whose employers might assign them to work on anything related to cygwin are under no obligation to work on other people's problems. > And what about the usage of other windows debuggers ? Does they have > also such specific exception hiding support ? If not will there be a > manual how to disable this internal messages ? Cygwin does not support the use of "other" debuggers. Cygwin is based around the GNU toolchain. We do not attempt compatibility with MSVC or WinDbg. > As summary, I don't think that patching gdb is the best solution. However your conclusions are based on a faulty understanding of the situation: > It > would be better to limit these exception to the cygwin dll and to hide > this message to the rest. The issue is not "limiting" the exceptions, which are already and always have been innately limited by their very nature; nothing further up the stack than the SEH handler frame will ever know the slightest thing about them. It is only when a *DEBUGGER* is controlling the flow of the program that it is even *possible* for anything to get in there ahead of the standard win32 exception handling mechanism that cygwin is already using to do what you ask. I recommend you do not post to this thread again until you have read 1) The cygwin user guide 2) The cygwin FAQ 3) The MSDN documentation about __try ... __except 3) Matt Pietrek's classic article from MSJ '97 about the internals of SEH. because you're just repeating yourself now. cheers, DaveK -- Can't think of a witty .sigline today.... -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/