new gdb/gdba code has bug with absolute source filenames

new gdb/gdba code has bug with absolute source filenames

[Bruce Stephens]

With a file (whose contents don't matter much) hello.c in /tmp.

     gcc -g3 -o hello hello.c

Then I can debug hello fine with the new M-x gdb.

If I compile it thus:

     gcc -g3 -o hello /tmp/hello.c

then when I do M-x gdb, and select gdb --annotate=3 hello, I see the
assembler code for main rather than C source code.

Obviously this is only a minor bug---overall the new modes are very
nice, even compared to the very usable previous version.

Re: new gdb/gdba code has bug with absolute source filenames

[Andreas Schwab]

Bruce Stephens <bruce.stephens@isode.com> writes:

> With a file (whose contents don't matter much) hello.c in /tmp.
>
>      gcc -g3 -o hello hello.c
>
> Then I can debug hello fine with the new M-x gdb.
>
> If I compile it thus:
>
>      gcc -g3 -o hello /tmp/hello.c
>
> then when I do M-x gdb, and select gdb --annotate=3 hello, I see the
> assembler code for main rather than C source code.

This is because gdb-frame-handler can't handle word wrapping in the
ouput of "info frame".  Should be fixed now.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: new gdb/gdba code has bug with absolute source filenames

[Nick Roberts]

> > With a file (whose contents don't matter much) hello.c in /tmp.
> >
> >      gcc -g3 -o hello hello.c
> >
> > Then I can debug hello fine with the new M-x gdb.
> >
> > If I compile it thus:
> >
> >      gcc -g3 -o hello /tmp/hello.c
> >
> > then when I do M-x gdb, and select gdb --annotate=3 hello, I see the
> > assembler code for main rather than C source code.

> This is because gdb-frame-handler can't handle word wrapping in the
> ouput of "info frame".  Should be fixed now.

I've not considered word wrapping. I can see that this would create problems
but I don't think this fixes the problem stated above as it happens before
execution has started, when "info frame" just gives "No stack." The source code
is located for Emacs with the GDB command "info source".

Bruce, when you see the assembler code for main rather than C source code
what does GDB say when you type "info source" in the GUD buffer? I can't
duplicate this problem. What operating system, version of GDB, gcc etc
are you using?

Andreas, I imagine other handlers in gdb-ui.el can't handle word wrapping so
I guess that running GDB command, "set width 0", on initialisation will help.


    Nick                                         http://www.nick.uklinux.net

Re: new gdb/gdba code has bug with absolute source filenames

[Bruce Stephens]

Nick Roberts <nick@nick.uklinux.net> writes:

[...]

> I've not considered word wrapping. I can see that this would create
> problems but I don't think this fixes the problem stated above as it
> happens before execution has started, when "info frame" just gives
> "No stack." The source code is located for Emacs with the GDB
> command "info source".

Actually, it did seem to fix the problem for the test example.  But
didn't seem to for a real program with a much longer file name.

> Bruce, when you see the assembler code for main rather than C source code
> what does GDB say when you type "info source" in the GUD buffer?

It says:

(gdb) info source
Current source file is /tmp/hello.c
Located in /tmp/hello.c
Contains 6 lines.
Source language is c.
Compiled with DWARF 2 debugging format.
Includes preprocessor macro info.

> I can't duplicate this problem. What operating system, version of
> GDB, gcc etc are you using?

Debian GNU/Linux unstable, i386, gdb 6.0-debian, gcc version 3.3.3
20031229 (prerelease) (Debian).

> Andreas, I imagine other handlers in gdb-ui.el can't handle word
> wrapping so I guess that running GDB command, "set width 0", on
> initialisation will help.

True.  As you suggest, though, it's probably not enough: show width
shows that width is 80, so probably that's enough for this example.

I used edebug on gdb-source-info.  When it starts,
*partial-output-hello* contains:

Current source file is /tmp/hello.c
Located in /tmp/hello.c
Contains 6 lines.
Source language is c.
Compiled with DWARF 2 debugging format.
Includes preprocessor macro info.

For a hello.c compiled with "gcc -g3 -o hello hello.c" (i.e., some
relative path, I guess), it contains:

Current source file is hello.c
Compilation directory is /tmp
Located in /tmp/hello.c
Contains 6 lines.
Source language is c.
Compiled with DWARF 2 debugging format.
Includes preprocessor macro info.

Perhaps I'm being naive, but it looks to me like gdb-source-info ought
to be looking at "Located in ..." and just believing it.  (Possibly
this wouldn't work for Windows or older gdbs or something.)

Re: new gdb/gdba code has bug with absolute source filenames

[Nick Roberts]

 > > Bruce, when you see the assembler code for main rather than C source code
 > > what does GDB say when you type "info source" in the GUD buffer?
 > 
 > It says:
 > 
 > (gdb) info source
 > Current source file is /tmp/hello.c
 > Located in /tmp/hello.c
 > Contains 6 lines.
 > Source language is c.
 > Compiled with DWARF 2 debugging format.
 > Includes preprocessor macro info.

Emacs doesn't find the source because "info source" doesn't output
the line with the compilation directory. Compare this with:

 > Current source file is hello.c
 > Compilation directory is /tmp   <-
 > Located in /tmp/hello.c
 > Contains 6 lines.
 > Source language is c.
 > Compiled with DWARF 2 debugging format.
 > Includes preprocessor macro info.

I don't know if this is a bug in gdb or gcc or normal output. I don't see why
gdb can't find the compilation directory from the executable. You used 
gcc version 3.3.3, is that a stable version?

 > Perhaps I'm being naive, but it looks to me like gdb-source-info ought
 > to be looking at "Located in ..." and just believing it.  (Possibly
 > this wouldn't work for Windows or older gdbs or something.)

It *does* use "Located in ...". Below is a patch that should work in your
case. I'm not sure whether I should commit it to the repository though.


    Nick                                         http://www.nick.uklinux.net



*** gdb-ui.el.~1.54.~	2004-01-07 23:04:35.000000000 +0000
--- gdb-ui.el	2004-01-08 10:09:17.000000000 +0000
***************
*** 1706,1719 ****
  buffers."
    (goto-char (point-min))
    (if (search-forward "directory is " nil t)
!       (progn
! 	(if (looking-at "\\S-*:\\(\\S-*\\)")
! 	    (setq gdb-cdir (match-string 1))
! 	  (looking-at "\\S-*")
! 	  (setq gdb-cdir (match-string 0)))
! 	(search-forward "Located in ")
  	(looking-at "\\S-*")
! 	(setq gdb-main-file (match-string 0)))
      (setq gdb-view-source nil))
    (delete-other-windows)
    (switch-to-buffer gud-comint-buffer)
--- 1706,1718 ----
  buffers."
    (goto-char (point-min))
    (if (search-forward "directory is " nil t)
!       (if (looking-at "\\S-*:\\(\\S-*\\)")
! 	  (setq gdb-cdir (match-string 1))
  	(looking-at "\\S-*")
! 	(setq gdb-cdir (match-string 0))))
!   (if (search-forward "Located in " nil t)
!       (if (looking-at "\\S-*")
! 	  (setq gdb-main-file (match-string 0)))
      (setq gdb-view-source nil))
    (delete-other-windows)
    (switch-to-buffer gud-comint-buffer)

Re: new gdb/gdba code has bug with absolute source filenames

[Andreas Schwab]

Nick Roberts <nick@nick.uklinux.net> writes:

> Andreas, I imagine other handlers in gdb-ui.el can't handle word
> wrapping

I've looked over the other handlers, and they seem to be ok.

> so I guess that running GDB command, "set width 0", on initialisation
> will help.

I don't think this is desireable, since it causes all output to not be
wrapped, which is not nice when printing large values.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: new gdb/gdba code has bug with absolute source filenames

[Andreas Schwab]

Bruce Stephens <Bruce.Stephens@isode.com> writes:

> Actually, it did seem to fix the problem for the test example.  But
> didn't seem to for a real program with a much longer file name.

Can you step through gdb-frame-handler with edebug and look at gdb's
output in gdb-partial-output-buffer?  I tried it with real long filenames
and function names, and it didn't fail for me.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: new gdb/gdba code has bug with absolute source filenames

[Bruce Stephens]

Andreas Schwab <schwab@suse.de> writes:

> Bruce Stephens <Bruce.Stephens@isode.com> writes:
>
>> Actually, it did seem to fix the problem for the test example.  But
>> didn't seem to for a real program with a much longer file name.
>
> Can you step through gdb-frame-handler with edebug and look at gdb's
> output in gdb-partial-output-buffer?

I don't need to.  The problem is right at the beginning.  As Nick
pointed out, for the broken case, gdb doesn't report the compilation
directory, so the first test fails, and gdb-view-source is set to nil.

> I tried it with real long filenames and function names, and it
> didn't fail for me.

I no longer think that it's length.  I think it's that absolute and
relative filenames end up different, for some reason.  I guess this is
the kind of thing that may well vary depending on debugging format,
compiler, and platform.

[...]

Re: new gdb/gdba code has bug with absolute source filenames

[Bruce Stephens]

Nick Roberts <nick@nick.uklinux.net> writes:

[...]

> I don't know if this is a bug in gdb or gcc or normal output. I
> don't see why gdb can't find the compilation directory from the
> executable. You used gcc version 3.3.3, is that a stable version?

No.  I get the same with Debian's gcc-3.2, which is 3.2.3 (possibly
with minor Debian patches).

>  > Perhaps I'm being naive, but it looks to me like gdb-source-info ought
>  > to be looking at "Located in ..." and just believing it.  (Possibly
>  > this wouldn't work for Windows or older gdbs or something.)
>
> It *does* use "Located in ...". Below is a patch that should work in your
> case. I'm not sure whether I should commit it to the repository though.

You're right.  I was suggesting it shouldn't be interested in the
compilation directory, but that probably *is* naive.

Your patch seems right to me, but I can understand your
uncertainty---this is probably something that shouldn't happen.

[...]

Re: new gdb/gdba code has bug with absolute source filenames

[Nick Roberts]

 > > so I guess that running GDB command, "set width 0", on initialisation
 > > will help.
 > 
 > I don't think this is desireable, since it causes all output to not be
 > wrapped, which is not nice when printing large values.

I agree. I will revert this change.

>From the e-mail to Bruce Stephens:

> Can you step through gdb-frame-handler with edebug and look at gdb's
> output in gdb-partial-output-buffer?  I tried it with real long filenames
> and function names, and it didn't fail for me.

A good way to look at this output is to select gdb-partial-output-buffer and
type undo. That way you can cycle back through its history. In the past I have
found that edebug plays havoc with real time aspects of the process filter.


    Nick                                         http://www.nick.uklinux.net

Re: new gdb/gdba code has bug with absolute source filenames

[Bruce Stephens]

Nick Roberts <nick@nick.uklinux.net> writes:

[...]

> A good way to look at this output is to select
> gdb-partial-output-buffer and type undo. That way you can cycle back
> through its history. In the past I have found that edebug plays
> havoc with real time aspects of the process filter.

That's useful to know.  In this case, though, I don't see that it
would help: I can see the differing behaviour using gdb in a terminal.
gdb isn't showing the compilation directory in this case, whereas with
a relative filename ("gcc-3.2 -g3 -o hello ./hello.c") it does.  I'd
guess details of how gdb-partial-output-buffer evolves probably
doesn't matter.

I don't know which program is at fault.

bruce% gcc-3.2 -g3 -o hello /tmp/hello.c
bruce% gdb hello
GNU gdb 6.0-debian
Copyright 2003 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-linux"...
(gdb) break main
Breakpoint 1 at 0x8048340: file /tmp/hello.c, line 4.
(gdb) run
Starting program: /tmp/hello
 
Breakpoint 1, main () at /tmp/hello.c:4
4       exit(0);
(gdb) info source
Current source file is /tmp/hello.c
Located in /tmp/hello.c
Contains 6 lines.
Source language is c.
Compiled with DWARF 2 debugging format.
Includes preprocessor macro info.

Re: new gdb/gdba code has bug with absolute source filenames

[Nick Roberts]

> I don't know which program is at fault.

Looking more carefully, I can reproduce this problem. I think this is normal
output. GDB only records a compilation directory if it makes sense. This is
used to help find the source code. If the source is in a different directory
to where the compilation is done, as it might be with

gcc -g3 -o hello /tmp/hello.c

then it might not help.

Since I think this is normal output, I've committed the changes in gdb-ui.el
to allow for this, to the CVS repository.


    Nick                                         http://www.nick.uklinux.net