Re: text file formats

[Bob Rossi <bob_rossi at cox dot net>]

On Thu, Apr 06, 2006 at 06:35:41AM +0300, Eli Zaretskii wrote:
> > Date: Wed, 5 Apr 2006 23:27:02 -0400
> > From: Bob Rossi <bob_rossi@cox.net>
> > 
> > > I have no idea what you mean.  GDB gets line numbers from debug info,
> > > of course; where else would it get them?
> > 
> > Does the debug info actually say, "at line 100 symbol foo() exists?"
> 
> No, it says, for every source line, which PC addresses correspond to
> that source line.  That is all GDB needs to know, because it
> manipulates PC addresses (i.e. addresses in the .text section).
> 
> For symbols, the debug info says that symbol `foo' is stored in the
> .text or .data section (or .bss or something else) at address NNN.

OK, this is interesting in brings up 2 cases. (They may be the same
though).

The first is when I have a source file displayed, I need to make sure
that what the user see's as line N is what GDB/GCC think is line N. For
instance, 'b foo.c:N' must be the same line N that GDB/GCC think is line N.

The second case is when the user types 'b main'.
GDB will find the symbol and determine the line number.
    (gdb) b main
    Breakpoint 1 at 0x8048320: file main.c, line 4.
I need to make sure that line 4, is the same in GDB, as it is in CGDB.

I've created a small example, using unix/dos/mac text formats.
The files are attached for your viewing purposes.

The output of cat
    $ cat unix.c
    int
    unixf (int i)
    {
      return i;
    }
    bar@adam ~/tmp/foo
    $ cat dos.c
    int
    dosf (int i)
    {
      return i;
    }
    bar@adam ~/tmp/foo
    $ cat mac.c
    bar@adam ~/tmp/foo

The output of GDB's list and source command.

    (gdb) list unix.c:1
    1       int
    2       unixf (int i)
    3       {
    4         return i;
    5       }
    (gdb) info source
    Current source file is unix.c
    Compilation directory is /home/bar/tmp/foo
    Located in /home/ADAM/bar/tmp/foo/unix.c
    Contains 5 lines.
    Source language is c.
    Compiled with unknown debugging format.
    Does not include preprocessor macro info.

    (gdb) list dos.c:1
    1       int
    2       dosf (int i)
    3       {
    4         return i;
    5       }
    (gdb) info source
    Current source file is dos.c
    Compilation directory is /home/bar/tmp/foo
    Located in /home/ADAM/bar/tmp/foo/dos.c
    Contains 5 lines.
    Source language is c.
    Compiled with unknown debugging format.
    Does not include preprocessor macro info.
    (gdb) list mac.c:1
    (gdb) rn i;)
    (gdb) info source
    Current source file is mac.c
    Compilation directory is /home/bar/tmp/foo
    Located in /home/ADAM/bar/tmp/foo/mac.c
    Contains 1 line.
    Source language is c.
    Compiled with unknown debugging format.
    Does not include preprocessor macro info.
    (gdb)

GDB writes every line to the current line when listing the mac file.
It is overwritten via the "\r". Notice that the 'info source' command
thinks the file is 1 line long. This isn't correct IMO. Is it to anyone
else?

The breakpoint command on symbols. GDB apparently thinks the macf
function is at line 4, but thinks there is only 1 line in the file.

    (gdb) b unixf
    Breakpoint 2 at 0x8048313: file unix.c, line 4.
    (gdb) b dosf
    Breakpoint 3 at 0x804831b: file dos.c, line 4.
    (gdb) b macf
    Breakpoint 4 at 0x8048323: file mac.c, line 4.

Executing the program.

    (gdb) b unixf
    Breakpoint 1 at 0x8048313: file unix.c, line 4.
    (gdb) b dosf
    Breakpoint 2 at 0x804831b: file dos.c, line 4.
    (gdb) b macf
    Breakpoint 3 at 0x8048323: file mac.c, line 4.
    (gdb) r

    Breakpoint 1, unixf (i=1) at unix.c:4
    4         return i;
    (gdb) c

    Breakpoint 2, dosf (i=1) at dos.c:4
    4         return i;
    (gdb)

    Breakpoint 3, macf (i=1) at mac.c:4
    Line number 4 out of range; mac.c has 1 lines.
    (gdb)

I don't know what this warning message means. Should CGDB think there is
5 lines in the file or 1 to be consitent with GDB or with GCC?

None of this really has anything to do with mixed file formats. That
step is even more confusing.

Thanks,
Bob Rossi

Attachment: files.tar
Description: Unix tar archive