From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Kettenis To: pavenis@latnet.lv Cc: gdb@sourceware.cygnus.com, linux-kernel@vger.rutgers.edu Subject: Re: Problems with GDB-5.0 and recent Linux kernels (2.4.0-test1-ac[47]) Date: Sat, 03 Jun 2000 13:32:00 -0000 Message-id: <200006032031.e53KVha24685@delius.kettenis.local> References: <00060320465900.00261@hal> X-SW-Source: 2000-06/msg00037.html [ Apologies to those receiving two copies of this message. My ISP has managed to get one of its mail servers in ORBS again. Sigh ... ] From: Andris Pavenis Date: Sat, 3 Jun 2000 20:37:45 +0200 Have somebody tried GDB commands 'info float' and 'info reg' on a system running latest ac kernels. I'm getting coredump from gdb-5.0 on these commands. 2.4.0-test1 - seems that all works, no such problem 2.4.0-test1-ac4 and 2.4.0-test1-ac7 - gdb coredumps on these commands It seems to be some stack corruption. Smells like a kernel bug to me. Yep it is! The Pentium III FXSR, SSE support breaks changes the ABI of the ptrace(GETFPREGS, ...) interface in an incompatible way. The size of `struct user_i387_struct' has been changed, so the kernel writes beyond the space on the stack reserved by GDB, hence the stack corruption. The kernel folks will have to find another way to implement this. Probably by introducing a new ptrace request. A while back Jim Blandy implemented support for the SSE registers in GDB, based on a different kernel patch that implemented a GETXFPREGS requests. It also implements support for core dumps in a different way, using an extra section for the SSE registers. Take a look at the GDB 5.0 release, or the following URL: http://sourceware.cygnus.com/cgi-bin/cvsweb.cgi/src/gdb/i386-linux-nat.c?cvsroot=src It would be great, if the interface in the kernel could be compatible with Jim's implementation, since that would mean instant support for the SSE registers in GDB once the glibc headers have been updated. By the way, I suspect that the change to `struct user_i387_struct' also change the offset of the u_debugreg member of `struct user', and therefore will break GDB's support for hardware brea/watchpoints. Mark >From kevinb@cygnus.com Sat Jun 03 15:42:00 2000 From: Kevin Buettner To: Eli Zaretskii Cc: gdb@sourceware.cygnus.com Subject: Re: Proposal: convert function definitions to prototyped form Date: Sat, 03 Jun 2000 15:42:00 -0000 Message-id: <1000603224224.ZM1091@ocotillo.lan> References: <200006021539.LAA25912@texas.cygnus.com> <1000602191042.ZM30936@ocotillo.lan> <200006031058.GAA12885@indy.delorie.com> <1000603175039.ZM738@ocotillo.lan> <200006031837.OAA13278@indy.delorie.com> X-SW-Source: 2000-06/msg00038.html Content-length: 1444 On Jun 3, 2:37pm, Eli Zaretskii wrote: > > Date: Sat, 3 Jun 2000 10:50:39 -0700 > > From: Kevin Buettner > > > > That's why I wrote check-decls (see > > http://sourceware.cygnus.com/ml/gdb/2000-06/msg00028.html > > ) which takes the result of comparing (via diff -u) the original > > sources with the protoized sources and produces a C source file in > > which the portions from the protoized sources are used to construct > > prototypes and the portions from the original sources are used to > > construct (potentially?) corresponding function definitions. We can > > then invoke the C compiler (gcc -c -Wall) on the result and see what > > kinds of warnings and errors are produced. > > I saw that script, but I don't like the idea to depend on a human to > judge what GCC warnings are okay to ignore and what aren't. I'd > prefer an automated tool that would give a definite yes/no answer, if > that's possible. I see your point. If I do as Andrew suggests and prevent fix-decls from looking at the *-share directories, that will prevent the arg_type conflict which is responsible for the errors. That leaves only the exit() warning from standalone.c to worry about. I can probably devise a solution which will prevent that warning from occurring as well. Anyway... I will see if I can arrange it so that any error or warning indicates a problem and no errors or warnings indicates that all's well. Kevin >From ac131313@cygnus.com Sat Jun 03 18:18:00 2000 From: Andrew Cagney To: Kevin Buettner Cc: Eli Zaretskii , gdb@sourceware.cygnus.com Subject: Re: Proposal: convert function definitions to prototyped form Date: Sat, 03 Jun 2000 18:18:00 -0000 Message-id: <3939AE2C.BD44873A@cygnus.com> References: <200006021539.LAA25912@texas.cygnus.com> <1000602191042.ZM30936@ocotillo.lan> <200006031058.GAA12885@indy.delorie.com> <1000603175039.ZM738@ocotillo.lan> X-SW-Source: 2000-06/msg00039.html Content-length: 1012 Kevin Buettner wrote: > > On Jun 3, 6:58am, Eli Zaretskii wrote: > > > So with a script, we will always need a verification tool that can be > > trusted to find any potential bugs introduced by reformatting. > > Right. > > That's why I wrote check-decls (see > http://sourceware.cygnus.com/ml/gdb/2000-06/msg00028.html > ) which takes the result of comparing (via diff -u) the original > sources with the protoized sources and produces a C source file in > which the portions from the protoized sources are used to construct > prototypes and the portions from the original sources are used to > construct (potentially?) corresponding function definitions. We can > then invoke the C compiler (gcc -c -Wall) on the result and see what > kinds of warnings and errors are produced. Rather than -Wall (badly missnamed) I'd suggest several more carefully selected flags such as: -Wimplict -Wreturn-type -Wstrict-prototypes -Wmissing-declarations. No need to make life difficult for your self :-) Andrew >From ac131313@cygnus.com Sun Jun 04 19:57:00 2000 From: Andrew Cagney To: GDB Discussion Subject: 5.0 post mortem Date: Sun, 04 Jun 2000 19:57:00 -0000 Message-id: <393B16D9.E217DAA1@cygnus.com> X-SW-Source: 2000-06/msg00040.html Content-length: 4058 (FWIW, I don't know what happened to the gnu.announce posting - I definitly submitted it :-) Well before a 5.0.1 or 5.1 release is started its probably worth having a bit of a post-mortem (where the vultures can pick over the bones of what happened :-) Here are my random thoughts: o feature based not date based release criteria First lesson I learnt was that people don't like releases made on the basis of an arbitrary date. Instead the consensus was that a set of features should be identified and the release should be made once those features were included. In the end there was some give and take over what was in/out of the list. Given the size of the backlog from the previous release I think what we ended up with was pretty reasonable. Things that were dropped were either dropped because they had no active developer or because the problem was too difficult/complex for the expected time frame. o must have VS nice to have VS won't have  Once consequence of the first point was that I ended up maintaining (using the TODO file!) three separate lists. In doing this, I tried to avoid the situtation where people were only allowed to work on ``must have items''. If I had tried to do that I think development would have simply stagnated. Instead I tried to categorize the feature list based on those three criteria. They would then be moved depending on what I perceved as the current reality. I figured ``must have'' wasn't much use if no one was willing to work on it. Besides, if someone implemented a ``might have'' or ``won't have'' who am I to argue :-) I tried to apply the ``won't have'' where I felt that there was more benefit in getting the work into the follow on release than trying to squeeze it into the current release. As a category, ``won't have'' is only going to work if there are regular releases and people can build up confidence in it. I don't know what people think of me using the TODO list as the tracking mechanism. I also don't know what people thought of my fairly abitrary (at times) re-aranging of the three lists. o I need to remember to use the gdb-testers mailing list When putting up release candidates I need to remember to post them to gdb-testers (which has a different audience to gdb-patches and the like). On more than one occasion I simply forgot. o A better way of tracking test results I tried using the TODO file for that however I don't think it was very successful. Having public test farms like netwinder.org are probably a step in the right direction. (I just wish they would include the test results on the main page so I didn't have to download that summary.log :-) I'm fairly skeptical towards idea's that involve people maintaining pages by hand. o I think the branch timing was about right Comparing the changes made to the trunk/branch, I think, in the end, the 5.0 branch was cut at about the right time. The emphasis was on getting the 5.0 feature list resolved (fixed or discarded) and then cutting the branch. o we need more tests The old perennial. There are never too many tests. My personal opinion is that, once the branch, has been cut it is almost too late to try to fix bugs the test suite is identifying. Instead they should be documented. The emphasis should instead be put on keeping the trunk in good condition so it can be branched at any time. o give that final release candidate ~7 days For those that don't know, I received e-mail of a djgpp problem just after I'd put the final release on sourceware but before gnu.org. o ftp.gnu.org is first not last Following on from the above, get the final release candidate onto ftp.gnu.org first not last. That way the cut off date is extended. o the mechanics worked The mechanical process of spinning a release worked without a hitch - the nightly build is using it (and hence testing it). nice day for it, Andrew >From benoit.millot@cstelecom.com Mon Jun 05 00:46:00 2000 From: "Benoit MILLOT" To: "gdb@sourceware.cygnus.com" Subject: Symbol file information ? Date: Mon, 05 Jun 2000 00:46:00 -0000 Message-id: <393B5ADE.73C4BC32@cstelecom.com> X-SW-Source: 2000-06/msg00041.html Content-length: 360 Where can i find any information on gdb symbol table? I works on m68 target. I couldn't read debugging symbol, variables or functions on gdb from executable file (ieee format issued of microtech tools). After compilation and link, the map file contains symbol table. So i suppose it is possible to convert the map information into gdb symbol table. Thanks.