From mboxrd@z Thu Jan 1 00:00:00 1970 From: "debashis mahata" To: Subject: FW: GDB 5.1 on Solaris 2.8 Date: Tue, 27 Nov 2001 03:58:00 -0000 Message-id: <000701c1773a$36039ee0$73b17fc0@8420044-mahatad.wipro.com> X-SW-Source: 2001-11/msg00285.html Looks like gdb list don't accept messages larger than 100000 bytes... This time I am attaching just diff.txt ... -----Original Message----- From: Debashis Mahata [ mailto:debashis.mahata@wipro.com ] Sent: Tuesday, November 27, 2001 2:51 PM To: Albert Chin-A-Young Cc: gdb@sources.redhat.com Subject: RE: GDB 5.1 on Solaris 2.8 Hi Albert, I am marking this mail to gdb list for others benefit/comments. Originally I had made changes on GDB 4.18. Along with these changes, I also had some other changes which are not related to the current problem. Currently I have source code of GDB 5.0 in my machine. So I am attaching three files (taken from GDB 5.0) where I made the changes for '/' and double ';' problem. The '/' problem in N_SO stab looks like a bug in compiler since it violates the documentation and probably SUN should provide a patch for that in future. My fix for this problem is in file partial-stab.h and dbxread.c. The current fix might be Solaris specific (I am not very sure what will happen if some compiler generate single N_SO instead of two as in case of Solaris). Although a generic fix is not required for me at this moment, any generic fix is welcome. I have placed the fix for double ';' in file stabsread.c. Stab document does not says that the structure and unions should ends with two consecutive ';'. GDB logic should not assume two consecutive ';' at the end. Either SUN should also fix this or otherwise a permanent fix is required in GDB. I am attaching the updated version of partial-stab.h, dbxread.c, stabsread.c, and diff.txt . Thanks, debashis mahata. > -----Original Message----- > From: Albert Chin-A-Young [ mailto:china@thewrittenword.com ] > Sent: Monday, November 26, 2001 9:27 PM > To: debashis mahata > Subject: Re: GDB 5.1 on Solaris 2.8 > > > On Mon, Nov 26, 2001 at 09:39:55AM +0500, debashis mahata wrote: > > Because of that GDB takes "/h/mahatad/DBG/GDB" as a file name. The > > corresponding code is in the partial-stab.h - > > case N_SO: > > { > > .... > > p = strrchr (namestring, '/'); > > if (p && *(p + 1) == '\000') > > continue; /* Simply ignore directory name SOs */ > > > > } > > I have put some fix for these two places in my local GDB source. After > > the fix - > > Can you forward your local patch to me? > > -- > albert chin (china@thewrittenword.com) > >From john@drystone.co.uk Tue Nov 27 04:47:00 2001 From: John Hedges To: Eli Zaretskii Cc: gdb@sourceware.cygnus.com Subject: Re: Problem with fld on i686 Date: Tue, 27 Nov 2001 04:47:00 -0000 Message-id: References: X-SW-Source: 2001-11/msg00286.html Content-length: 749 On Tuesday 27 Nov 2001 11:18 am, Eli Zaretskii wrote: > If the code _is_ correct (I think it is), but the results aren't, then > the fact that static_cast was used in the C++ program is irrelevant, > right? Correct - static_cast is irrelevant if we assume it compiled correctly. The disassembly looks ok to me too but I'm no asm expert. > > The problem does not occur when run outside the debugger, nor in a > > minimal test program. > > This suggests that perhaps the FPU state is not saved/restored correctly > across task switches. What OS is that? Can you try a different version > of the same OS, or some similar but not identical OS? OS is Linux 2.2.14-5.0. Problem does not occur with Linux 2.2.16 on a different (but stil i686) box. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12957 invoked by alias); 27 Nov 2001 11:58:30 -0000 Mailing-List: contact gdb-help@sourceware.cygnus.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 12686 invoked from network); 27 Nov 2001 11:57:20 -0000 Received: from unknown (HELO wiprom2mx2.wipro.com) (203.197.164.42) by hostedprojects.ges.redhat.com with SMTP; 27 Nov 2001 11:57:20 -0000 Received: from m2vwall3.wipro.com (m2vwall3.wipro.com [164.164.29.237]) by wiprom2mx2.wipro.com (8.11.3/8.11.3) with SMTP id fARBv6f14258 for ; Tue, 27 Nov 2001 17:27:08 +0530 (IST) Received: from 192.168.2.18 by m2vwall3.wipro.com (InterScan E-Mail VirusWall NT); Tue, 27 Nov 2001 17:26:21 +0530 Received: from m2vwall3.wipro.com ([164.164.29.237]) by sarovar.mail.wipro.com (Netscape Messaging Server 4.15) with SMTP id GNGJTO00.2IN for ; Tue, 27 Nov 2001 17:26:12 +0530 Received: from 192.168.223.18 by m2vwall3.wipro.com (InterScan E-Mail VirusWall NT); Tue, 27 Nov 2001 17:25:35 +0530 Received: from 8420044-mahatad.wipro.com ([192.127.177.115]) by platinum.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GNGJSE00.9LB for ; Tue, 27 Nov 2001 17:25:26 +0530 From: "debashis mahata" To: Subject: FW: GDB 5.1 on Solaris 2.8 Date: Fri, 16 Nov 2001 17:10:00 -0000 Message-ID: <000701c1773a$36039ee0$73b17fc0@8420044-mahatad.wipro.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0008_01C17768.4FBBDAE0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 X-SW-Source: 2001-11/txt/msg00178.txt.bz2 Message-ID: <20011116171000.o8E27KW6o6lPKVaSYSa1n0ex-Ac3jG3WioYmJZeujsU@z> This is a multi-part message in MIME format. ------=_NextPart_000_0008_01C17768.4FBBDAE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-length: 2370 Looks like gdb list don't accept messages larger than 100000 bytes... This time I am attaching just diff.txt ... -----Original Message----- From: Debashis Mahata [mailto:debashis.mahata@wipro.com] Sent: Tuesday, November 27, 2001 2:51 PM To: Albert Chin-A-Young Cc: gdb@sources.redhat.com Subject: RE: GDB 5.1 on Solaris 2.8 Hi Albert, I am marking this mail to gdb list for others benefit/comments. Originally I had made changes on GDB 4.18. Along with these changes, I also had some other changes which are not related to the current problem. Currently I have source code of GDB 5.0 in my machine. So I am attaching three files (taken from GDB 5.0) where I made the changes for '/' and double ';' problem. The '/' problem in N_SO stab looks like a bug in compiler since it violates the documentation and probably SUN should provide a patch for that in future. My fix for this problem is in file partial-stab.h and dbxread.c. The current fix might be Solaris specific (I am not very sure what will happen if some compiler generate single N_SO instead of two as in case of Solaris). Although a generic fix is not required for me at this moment, any generic fix is welcome. I have placed the fix for double ';' in file stabsread.c. Stab document does not says that the structure and unions should ends with two consecutive ';'. GDB logic should not assume two consecutive ';' at the end. Either SUN should also fix this or otherwise a permanent fix is required in GDB. I am attaching the updated version of partial-stab.h, dbxread.c, stabsread.c, and diff.txt . Thanks, debashis mahata. > -----Original Message----- > From: Albert Chin-A-Young [mailto:china@thewrittenword.com] > Sent: Monday, November 26, 2001 9:27 PM > To: debashis mahata > Subject: Re: GDB 5.1 on Solaris 2.8 > > > On Mon, Nov 26, 2001 at 09:39:55AM +0500, debashis mahata wrote: > > Because of that GDB takes "/h/mahatad/DBG/GDB" as a file name. The > > corresponding code is in the partial-stab.h - > > case N_SO: > > { > > .... > > p = strrchr (namestring, '/'); > > if (p && *(p + 1) == '\000') > > continue; /* Simply ignore directory name SOs */ > > > > } > > I have put some fix for these two places in my local GDB source. After > > the fix - > > Can you forward your local patch to me? > > -- > albert chin (china@thewrittenword.com) > ------=_NextPart_000_0008_01C17768.4FBBDAE0 Content-Type: text/plain; name="diff.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="diff.txt" Content-length: 2189 $ct diff -ser partial-stab.h partial-stab.h.update cleartool: Warning: No type info, using text file type manager. ******************************** <<< file 1: partial-stab.h >>> file 2: partial-stab.h.update ******************************** -----[258 changed to 258]----- < --- > #if 0 -----[after 261 inserted 262-270]----- > #else > /* Sun WorkShop 6 update 2 C 5.3 does not generate the last back > slash for the first N_SO stab. This is a bug with the compiler > since it violates the documentation. The code under '#else' > should be removed if SUN fix this problem.*/ > > if (first_so_symnum == symnum) > continue; /* Simply ignore directory name SOs */ > #endif $ct diff -ser dbxread.c dbxread.c.update cleartool: Warning: No type info, using text file type manager. ******************************** <<< file 1: dbxread.c >>> file 2: dbxread.c.update ******************************** -----[after 2141 inserted 2142]----- > #if 0 -----[after 2142 inserted 2144-2166]----- > #else > { > /* Sun WorkShop 6 update 2 C 5.3 does not generate the last back > slash for the first N_SO stab. This is a bug with the compiler > since it violates the documentation. The code under "#else' > should be removed if SUN fix this problem.*/ > > int len = strlen(name); > char * buf; > > if (name[len-1] != '/') > { > buf = (char *)xmalloc(len+2); > sprintf(buf, "%s%c\0", name, '/'); > } > else > buf = name; > start_symtab (buf, NULL, valu); > > if (name[len-1] != '/') > free(buf); > } > #endif $ct diff -ser stabsread.c stabsread.c.update cleartool: Warning: No type info, using text file type manager. ******************************** <<< file 1: stabsread.c >>> file 2: stabsread.c.update ******************************** -----[3557-3558 changed to 3557-3559]----- < < while (**pp != ';') --- > /* Stab string for structure/union does not end with two ';' in > Sun WorkShop 6 update 2 C 5.3 */ > while (**pp != ';' && **pp != '\0') ------=_NextPart_000_0008_01C17768.4FBBDAE0 Content-Type: text/plain; name="InterScan_Disclaimer.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="InterScan_Disclaimer.txt" Content-length: 855 ------------------------------------------------------------------------------------------------------------------------- Information transmitted by this E-MAIL is proprietary to Wipro and/or its Customers and is intended for use only by the individual or entity to which it is addressed, and may contain information that is privileged, confidential or exempt from disclosure under applicable law. If you are not the intended recipient or it appears that this mail has been forwarded to you without proper authority, you are notified that any use or dissemination of this information in any manner is strictly prohibited. In such cases, please notify us immediately at mailto:mailadmin@wipro.com and delete this mail from your records. ---------------------------------------------------------------------------------------------------------------------- ------=_NextPart_000_0008_01C17768.4FBBDAE0--