From: "debashis mahata" <debashis.mahata@wipro.com>
To: Eli Zaretskii <eliz@is.elta.co.il>
Cc: Dan Nicolaescu <dann@godzilla.ICS.UCI.EDU>, gdb@sources.redhat.com
Subject: Re: GDB 5.1 on Solaris 2.8
Date: Mon, 26 Nov 2001 04:16:00 -0000 [thread overview]
Message-ID: <70beb6f093.6f09370beb@wipro.com> (raw)
Hi all,
I also hit this problem. Probably this is a problem with
"Sun WorkShop 6
update 2 C 5.3" compiler. This compiler does not generate the last back
slash ("/") in the first N_SO stab that represents the directory name.
The second N_SO is actually represents the source file name. GDB
identify the directory name using the last '/' as an indicator. For the
program
$pwd
/h/mahatad/DBG/GDB
$cat a.c
int
main (void) {
int a = 1;
}
$
The N_SO stab entries are -
With "Sun WorkShop 6 update 2 C 5.3" -
"/h/mahatad/DBG/GDB" ,64, 0, 0, 0
"a.c" ,64, 0, 3, 0
With the old version of compiler -
"/h/mahatad/DBG/GDB/" ,64, 0, 0, 0
"a.c" ,64, 0, 3, 0
It is clear that new compiler does not generate the last '/' in first
N_SO stab.
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 */
}
GDB is not ignoring the directory name. This requires a fix. Most
probably another fix is required in dbxread.c (function -
process_one_symbol()) for N_SO case. The corresponding code -
case N_SO:
.....
start_stabs ();
start_symtab (name, NULL, valu);
record_debugformat ("stabs");
break;
Here, the 'name' is again a directory name without the last back slash.
I have put some fix for these two places in my local GDB source. After
the fix -
$cc -V
cc: Sun WorkShop 6 update 2 C 5.3 2001/05/15
$cc -g -xs a.c
$/vob/opnpde/solaris-sparc/debug/package/00.00.00.00/bin/gdb a.out
GNU gdb 4.18 + 02.00.01.00 (sparc64-sun-solaris2.7),
Copyright 1998 Free Software Foundation, Inc...
(gdb) list
1 int
2 main (void) {
3 int a = 1;
4 }
(gdb)
I found another problem with this compiler. The structures are suppose
to end with two consecutive ';'. GDB logic depends upon that. But this
compiler generate only one ';'. Just for an example -
For the structure
struct node{
int i;
char c;
};
With "Sun WorkShop 6 update 2 C 5.3" -
"node:T(0,21)=s8i:(0,3),0,32;c:(0,1),32,8;" ,80, 0, 8, 0
With the old version of compiler -
"node:T(0,21)=s8i:(0,3),0,32;c:(0,1),32,8;;" ,80, 0, 8, 0
Again it is clear the new compiler does not generate the last ';' and
this will break the GDB logic in read_struct_fields() function (file:
stabsread.c).
Thanks,
debashis mahata
----- Original Message -----
From: Eli Zaretskii <eliz@is.elta.co.il>
Date: Sunday, November 25, 2001 2:08 pm
Subject: Re: GDB 5.1 on Solaris 2.8
>
> On Sat, 24 Nov 2001, Dan Nicolaescu wrote:
>
> > > $ gdb a.out
> > > gdb> list
> > > /opt/src/devel/gdb-5.1: Is a directory.
> >
> > Well, it works for me... But it seems that you have a newer
> version of
> > the Sun compiler than I do:
> >
> > cc -V
> > cc: Sun WorkShop 6 update 1 C 5.2 2000/09/11
>
> Thanks to everyone who replied; -xs seems to be what I need.
>
> The example above works for me as well, but I have an even older
> version of the compiler.
>
> However, it sounds like turning on optimizations makes GDB debugging
> impossible with this compiler. Is that expected? Am I spoiled by
> GCC?
>
WARNING: multiple messages have this Message-ID
From: "debashis mahata" <debashis.mahata@wipro.com>
To: Eli Zaretskii <eliz@is.elta.co.il>
Cc: Dan Nicolaescu <dann@godzilla.ICS.UCI.EDU>, gdb@sources.redhat.com
Subject: Re: GDB 5.1 on Solaris 2.8
Date: Wed, 14 Nov 2001 00:50:00 -0000 [thread overview]
Message-ID: <70beb6f093.6f09370beb@wipro.com> (raw)
Message-ID: <20011114005000.uyHecycduzXqPdhdZkuMYA2bB_NSdGWackfIA59GYS0@z> (raw)
Hi all,
I also hit this problem. Probably this is a problem with
"Sun WorkShop 6
update 2 C 5.3" compiler. This compiler does not generate the last back
slash ("/") in the first N_SO stab that represents the directory name.
The second N_SO is actually represents the source file name. GDB
identify the directory name using the last '/' as an indicator. For the
program
$pwd
/h/mahatad/DBG/GDB
$cat a.c
int
main (void) {
int a = 1;
}
$
The N_SO stab entries are -
With "Sun WorkShop 6 update 2 C 5.3" -
"/h/mahatad/DBG/GDB" ,64, 0, 0, 0
"a.c" ,64, 0, 3, 0
With the old version of compiler -
"/h/mahatad/DBG/GDB/" ,64, 0, 0, 0
"a.c" ,64, 0, 3, 0
It is clear that new compiler does not generate the last '/' in first
N_SO stab.
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 */
}
GDB is not ignoring the directory name. This requires a fix. Most
probably another fix is required in dbxread.c (function -
process_one_symbol()) for N_SO case. The corresponding code -
case N_SO:
.....
start_stabs ();
start_symtab (name, NULL, valu);
record_debugformat ("stabs");
break;
Here, the 'name' is again a directory name without the last back slash.
I have put some fix for these two places in my local GDB source. After
the fix -
$cc -V
cc: Sun WorkShop 6 update 2 C 5.3 2001/05/15
$cc -g -xs a.c
$/vob/opnpde/solaris-sparc/debug/package/00.00.00.00/bin/gdb a.out
GNU gdb 4.18 + 02.00.01.00 (sparc64-sun-solaris2.7),
Copyright 1998 Free Software Foundation, Inc...
(gdb) list
1 int
2 main (void) {
3 int a = 1;
4 }
(gdb)
I found another problem with this compiler. The structures are suppose
to end with two consecutive ';'. GDB logic depends upon that. But this
compiler generate only one ';'. Just for an example -
For the structure
struct node{
int i;
char c;
};
With "Sun WorkShop 6 update 2 C 5.3" -
"node:T(0,21)=s8i:(0,3),0,32;c:(0,1),32,8;" ,80, 0, 8, 0
With the old version of compiler -
"node:T(0,21)=s8i:(0,3),0,32;c:(0,1),32,8;;" ,80, 0, 8, 0
Again it is clear the new compiler does not generate the last ';' and
this will break the GDB logic in read_struct_fields() function (file:
stabsread.c).
Thanks,
debashis mahata
----- Original Message -----
From: Eli Zaretskii <eliz@is.elta.co.il>
Date: Sunday, November 25, 2001 2:08 pm
Subject: Re: GDB 5.1 on Solaris 2.8
>
> On Sat, 24 Nov 2001, Dan Nicolaescu wrote:
>
> > > $ gdb a.out
> > > gdb> list
> > > /opt/src/devel/gdb-5.1: Is a directory.
> >
> > Well, it works for me... But it seems that you have a newer
> version of
> > the Sun compiler than I do:
> >
> > cc -V
> > cc: Sun WorkShop 6 update 1 C 5.2 2000/09/11
>
> Thanks to everyone who replied; -xs seems to be what I need.
>
> The example above works for me as well, but I have an even older
> version of the compiler.
>
> However, it sounds like turning on optimizations makes GDB debugging
> impossible with this compiler. Is that expected? Am I spoiled by
> GCC?
>
next reply other threads:[~2001-11-26 4:16 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-11-26 4:16 debashis mahata [this message]
2001-11-14 0:50 ` debashis mahata
[not found] <ur9r8qpa0l0.fsf@totally-fudged-out-message-id>
2001-11-11 21:24 ` Dan Nicolaescu
2001-11-12 1:49 ` Eli Zaretskii
-- strict thread matches above, loose matches on Subject: below --
2001-11-11 13:41 Dan Nicolaescu
2001-11-11 18:14 ` gdb
2001-11-11 11:39 Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=70beb6f093.6f09370beb@wipro.com \
--to=debashis.mahata@wipro.com \
--cc=dann@godzilla.ICS.UCI.EDU \
--cc=eliz@is.elta.co.il \
--cc=gdb@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox