DWARF question

DWARF question

[Carlos Eduardo Seo]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello

I found something strange in a binary generated from a fortran code: two
compilation units for the same source file. Is that allowed by the DWARF
specification? The binary was generated from a single source file.

Thanks and regards,

- --
Carlos Eduardo Seo
Software Engineer
IBM Linux Technology Center
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG+snXqvq7Aov/qQARAl0CAJ4imtIbFD8u8rLBzEeZoRayKyWYHACfUsKE
hAQrPWhk2QlpZHCBhOAaEQs=
=tRmN
-----END PGP SIGNATURE-----

Re: DWARF question

[Daniel Jacobowitz]

On Wed, Sep 26, 2007 at 06:06:31PM -0300, Carlos Eduardo Seo wrote:
> I found something strange in a binary generated from a fortran code: two
> compilation units for the same source file. Is that allowed by the DWARF
> specification? The binary was generated from a single source file.

Yes, it happens in several cases, though I don't know why in your case.

-- 
Daniel Jacobowitz
CodeSourcery

Re: DWARF question

[Carlos Eduardo Seo]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

It's generating one compilation unit for the "main" program and another
one for a function called by that program. Both are implemented in the
same source file.


Carlos Eduardo Seo
Software Engineer
IBM Linux Technology Center
Phone: +55 19-2132-4339
T/L: 839-4339
E-Mail: eduseo@br.ibm.com


Daniel Jacobowitz wrote:
> On Wed, Sep 26, 2007 at 06:06:31PM -0300, Carlos Eduardo Seo wrote:
>> I found something strange in a binary generated from a fortran code: two
>> compilation units for the same source file. Is that allowed by the DWARF
>> specification? The binary was generated from a single source file.
> 
> Yes, it happens in several cases, though I don't know why in your case.
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG+tRrkuArJ/wDsWwRAizRAKC801NR6yOlitCL2YD3WK0v2zN8mgCgucXp
wrd5czl6wJv5xIrZnKJr0VU=
=TvHT
-----END PGP SIGNATURE-----

Re: DWARF question

[Carlos Eduardo Seo]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Carlos Eduardo Seo wrote:
> It's generating one compilation unit for the "main" program and another
> one for a function called by that program. Both are implemented in the
> same source file.
> 
> 
And the source is in Fortran. This another problem that happens in the
situation I described in this thread:
http://sourceware.org/ml/gdb/2007-09/msg00134.html
aside from that finding "main" problem.


The problem is that, when I try to set a breakpoint by line number in
this case, two things may happen:

1. if I set the breakpoint somewhere inside "main", it works.
2. if I set the breakpoint somewhere inside the function, it doesn't
work (i.e.  'No line xx in file "foo.f".').

In other words, it seems that GDB doesn't have the line number
information for that function.

In order to fix this, I can think about two approaches:

- - Make GDB read the two existing symtabs for that source file when the
binary is loaded; or
- - When a breakpoint by line number is called, GDB tries to look for that
line in the other symtabs corresponding to the current objfile.

What do you think?

Regards,

- --
Carlos Eduardo Seo
Software Engineer
IBM Linux Technology Center
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG/Vqbqvq7Aov/qQARAorRAJ9wLu3GrdBQr2W1jE+X/mDnmHV4nQCfZmWX
5FYKUlqCGlx0e6ZSFpK+qHQ=
=y1w8
-----END PGP SIGNATURE-----

Re: DWARF question

[Jim Blandy]

Carlos Eduardo Seo <cseo@linux.vnet.ibm.com> writes:
> Carlos Eduardo Seo wrote:
>> It's generating one compilation unit for the "main" program and another
>> one for a function called by that program. Both are implemented in the
>> same source file.
>> 
>> 
> And the source is in Fortran. This another problem that happens in the
> situation I described in this thread:
> http://sourceware.org/ml/gdb/2007-09/msg00134.html
> aside from that finding "main" problem.
>
>
> The problem is that, when I try to set a breakpoint by line number in
> this case, two things may happen:
>
> 1. if I set the breakpoint somewhere inside "main", it works.
> 2. if I set the breakpoint somewhere inside the function, it doesn't
> work (i.e.  'No line xx in file "foo.f".').
>
> In other words, it seems that GDB doesn't have the line number
> information for that function.
>
> In order to fix this, I can think about two approaches:
>
> - Make GDB read the two existing symtabs for that source file when the
> binary is loaded; or
> - When a breakpoint by line number is called, GDB tries to look for that
> line in the other symtabs corresponding to the current objfile.
>
> What do you think?

I've reproduced this in C:

  $ cat 1s2c.c
  #include <stdio.h>

  extern void foo (void);

  #ifdef FIRST
  int
  main (int argc, char **argv)
  {
    puts ("main");
    foo ();
    puts ("main again");
    return 0;
  }

  #else

  void
  foo (void)
  {
    puts ("foo");
  }

  #endif
  $ cat 1s2c.mk
  CFLAGS = -g
  CC = gcc

  all: 1s2c

  1s2c: 1s2c1.o 1s2c2.o
          $(CC) $(CFLAGS) $(LDFLAGS) $^ -o $@

  1s2c1.o: 1s2c.c
          $(CC) $(CFLAGS) $(CPPFLAGS) -c $< -o $@
  1s2c1.o: CFLAGS += -DFIRST
  1s2c2.o: 1s2c.c
          $(CC) $(CFLAGS) $(CPPFLAGS) -c $< -o $@

  clean:
          rm -f 1s2c 1s2c[12].o
  $ make -f 1s2c.mk clean all
  rm -f 1s2c 1s2c[12].o
  gcc -g -DFIRST  -c 1s2c.c -o 1s2c1.o
  gcc -g  -c 1s2c.c -o 1s2c2.o
  gcc -g  1s2c1.o 1s2c2.o -o 1s2c
  $ ~/gdb/exp/nat/gdb/gdb 1s2c
  GNU gdb 6.7.50-20070926-cvs
  Copyright (C) 2007 Free Software Foundation, Inc.
  License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
  This is free software: you are free to change and redistribute it.
  There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
  and "show warranty" for details.
  This GDB was configured as "i686-pc-linux-gnu"...
  Using host libthread_db library "/lib/libthread_db.so.1".
  (gdb) break 20
  No line 20 in file "1s2c.c".
  (gdb) break 10
  Breakpoint 1 at 0x80483a1: file 1s2c.c, line 10.
  (gdb) 

However, the problem isn't that GDB isn't reading the symtabs; given
some source file name S, GDB always reads full symbols for all
psymtabs whose names match S.  We can verify this:

  (gdb) maint info psymtabs
  { objfile /home/jimb/play/1s2c ((struct objfile *) 0x98d2de0)
    { psymtab 1s2c.c ((struct partial_symtab *) 0x98da7c4)
      readin yes
      fullname (null)
      text addresses 0x0 -- 0x0
      globals (none)
      statics (none)
      dependencies {
        psymtab 1s2c.c ((struct partial_symtab *) 0x98da774)
      }
    }
    { psymtab 1s2c.c ((struct partial_symtab *) 0x98da774)
      readin yes
      fullname (null)
      text addresses 0x80483c0 -- 0x80483d4
      globals (* (struct partial_symbol **) 0x98d8e94 @ 1)
      statics (* (struct partial_symbol **) 0x98d9060 @ 12)
      dependencies (none)
    }
    { psymtab 1s2c.c ((struct partial_symtab *) 0x98da720)
      readin yes
      fullname (null)
      text addresses 0x0 -- 0x0
      globals (none)
      statics (none)
      dependencies {
        psymtab 1s2c.c ((struct partial_symtab *) 0x98da628)
      }
    }
    { psymtab 1s2c.c ((struct partial_symtab *) 0x98da628)
      readin yes
      fullname (null)
      text addresses 0x8048384 -- 0x80483c0
      globals (* (struct partial_symbol **) 0x98d8e90 @ 1)
      statics (* (struct partial_symbol **) 0x98d9030 @ 12)
      dependencies (none)
    }
  }
  (gdb) maint info symtabs
  { objfile /home/jimb/play/1s2c ((struct objfile *) 0x98d2de0)
    { symtab 1s2c.c ((struct symtab *) 0x98e43fc)
      dirname /home/jimb/play
      fullname (null)
      blockvector ((struct blockvector *) 0x98e43ec) (primary)
      debugformat DWARF 2
    }
    { symtab 1s2c.c ((struct symtab *) 0x98db290)
      dirname /home/jimb/play
      fullname (null)
      blockvector ((struct blockvector *) 0x98db280) (primary)
      debugformat DWARF 2
    }
  }
  (gdb) 

There are no less than four partial symbol tables by the name of
1s2c.c --- for each CU, that's probably one for the .debug_info
compilation unit, and then one from the .debug_line info.  This is the
natural state of affairs.

When the user types 'break 20', GDB reads full symbols for both of the
CUs.

The real question here is, why isn't find_line_symtab doing its job?
Its comment says:

  /* Find line number LINE in any symtab whose name is the same as
     SYMTAB.

     If found, return the symtab that contains the linetable in which it was
     found, set *INDEX to the index in the linetable of the best entry
     found, and set *EXACT_MATCH nonzero if the value returned is an
     exact match.

     If not found, return NULL.  */

That sounds to me like it's meant to address exactly the case we have
here.  Could you take a look and tell us what you find?

Re: DWARF question

[Carlos Eduardo Seo]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Jim Blandy wrote:
> The real question here is, why isn't find_line_symtab doing its job?
> Its comment says:
>
>   /* Find line number LINE in any symtab whose name is the same as
>      SYMTAB.
>
>      If found, return the symtab that contains the linetable in which
it was
>      found, set *INDEX to the index in the linetable of the best entry
>      found, and set *EXACT_MATCH nonzero if the value returned is an
>      exact match.
>
>      If not found, return NULL.  */
>
> That sounds to me like it's meant to address exactly the case we have
> here.  Could you take a look and tell us what you find?
>
Good point Jim. I'll take a look at that. The only thing I noticed in
that function is that best_index always returns -1 when I try to set a
breakpoint by line number in that function. I'm going deeper into that
now.

One point I forgot to mention and I think it's relevant is that when I
load the binary with option '-readnow', that breakpoint by line number
in the function works.

- --
Carlos Eduardo Seo
Software Engineer
IBM Linux Technology Center
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG/Xrpqvq7Aov/qQARAu6SAJ4iVznN5AEUHGD7RoBYkzltuTJ+BACfRkjT
Ab3YtDRDloriOgDRoTxUS58=
=cr9I
-----END PGP SIGNATURE-----

Re: DWARF question

[Jim Blandy]

Carlos Eduardo Seo <cseo at linux.vnet.ibm.com> writes:
> Jim Blandy wrote:
>> The real question here is, why isn't find_line_symtab doing its job?
>> Its comment says:
>>
>>   /* Find line number LINE in any symtab whose name is the same as
>>      SYMTAB.
>>
>>      If found, return the symtab that contains the linetable in which
> it was
>>      found, set *INDEX to the index in the linetable of the best entry
>>      found, and set *EXACT_MATCH nonzero if the value returned is an
>>      exact match.
>>
>>      If not found, return NULL.  */
>>
>> That sounds to me like it's meant to address exactly the case we have
>> here.  Could you take a look and tell us what you find?
>>
> Good point Jim. I'll take a look at that. The only thing I noticed in
> that function is that best_index always returns -1 when I try to set a
> breakpoint by line number in that function. I'm going deeper into that
> now.
>
> One point I forgot to mention and I think it's relevant is that when I
> load the binary with option '-readnow', that breakpoint by line number
> in the function works.

What probably happens is that '-readnow' somehow affects the order in
which the full symtabs get put in the list.  I'm surprised that
breakpoints by line number in both main and the function work, but I
guess that has something to do with the nature of the bug in
find_line_symtab.

Re: DWARF question

[Carlos Eduardo Seo]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Jim Blandy wrote:
>
> What probably happens is that '-readnow' somehow affects the order in
> which the full symtabs get put in the list.  I'm surprised that
> breakpoints by line number in both main and the function work, but I
> guess that has something to do with the nature of the bug in
> find_line_symtab.
Here's what I got. The loop  'ALL_SYMTABS' has only one iteration
because 's->next' is NULL. So it seems that GDB isn't loading the
other symtab.

When I use '-readnow', both symtabs are there:

(top-gdb) p s->filename
$6 = 0x106a4930 "init.c"
(top-gdb) p (s->next)->filename
$7 = 0x1069cf10 "/usr/src/packages/BUILD/glibc-2.4/cc-nptl/csu/crti.S"
(top-gdb) p ((s->next)->next)->filename
$8 = 0x1069cc60 "test-main.f"
(top-gdb) p (((s->next)->next)->next)->filename
$9 = 0x1069c280 "test-main.f"
(top-gdb) p ((((s->next)->next)->next)->next)->filename
$10 = 0x1068d5c0 "crtsavres.S"
(top-gdb) p (((((s->next)->next)->next)->next)->next)->filename
$11 = 0x1068d2a0 "/usr/src/packages/BUILD/glibc-2.4/cc-nptl/csu/crtn.S"
(top-gdb) p (((((s->next)->next)->next)->next)->next)->next
$17 = (struct symtab *) 0x0

And the loop 'ALL_SYMTABS' work. So, it looks like the bug isn't in
this function. I'm going to look at where GDB populates the symtabs
list now.

Any thoughts?

Regards,

- --
Carlos Eduardo Seo
Software Engineer
IBM Linux Technology Center
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHATM8qvq7Aov/qQARAjvjAJ9gkyzimsdqWIcfomV92r2epC14RgCeIij7
aImDP4A6XiUgmIRbEnRhe+Q=
=dpf+
-----END PGP SIGNATURE-----

Re: DWARF question

[Jim Blandy]

Carlos Eduardo Seo <cseo at linux.vnet.ibm.com> writes:
> Jim Blandy wrote:
>>
>> What probably happens is that '-readnow' somehow affects the order in
>> which the full symtabs get put in the list.  I'm surprised that
>> breakpoints by line number in both main and the function work, but I
>> guess that has something to do with the nature of the bug in
>> find_line_symtab.
> Here's what I got. The loop  'ALL_SYMTABS' has only one iteration
> because 's->next' is NULL. So it seems that GDB isn't loading the
> other symtab.
>
> When I use '-readnow', both symtabs are there:
>
> (top-gdb) p s->filename
> $6 = 0x106a4930 "init.c"
> (top-gdb) p (s->next)->filename
> $7 = 0x1069cf10 "/usr/src/packages/BUILD/glibc-2.4/cc-nptl/csu/crti.S"
> (top-gdb) p ((s->next)->next)->filename
> $8 = 0x1069cc60 "test-main.f"
> (top-gdb) p (((s->next)->next)->next)->filename
> $9 = 0x1069c280 "test-main.f"
> (top-gdb) p ((((s->next)->next)->next)->next)->filename
> $10 = 0x1068d5c0 "crtsavres.S"
> (top-gdb) p (((((s->next)->next)->next)->next)->next)->filename
> $11 = 0x1068d2a0 "/usr/src/packages/BUILD/glibc-2.4/cc-nptl/csu/crtn.S"
> (top-gdb) p (((((s->next)->next)->next)->next)->next)->next
> $17 = (struct symtab *) 0x0
>
> And the loop 'ALL_SYMTABS' work. So, it looks like the bug isn't in
> this function. I'm going to look at where GDB populates the symtabs
> list now.
>
> Any thoughts?

(Vlad, this touches on some of the multi-breakpoint code.  If you're
interested, I'm using example code I posted up-thread.)

I think I see the problem.  First, check this out:

    (gdb) break 20
    No line 20 in file "1s2c.c".
    (gdb) break 10
    Breakpoint 1 at 0x80483a1: file 1s2c.c, line 10.
    (gdb) break 20
    Breakpoint 2 at 0x80483c6: file 1s2c.c, line 20.
    (gdb) 

So, for some reason setting a breakpoint on line 10 reads in both
symtabs, but setting one in line 20 does not.

What's going on is as follows:

When we type 'break 20', GDB needs to know what source file we're
referring to.  select_source_symtab says:

  /* Make the default place to list be the function `main'
     if one exists.  */
  if (lookup_symbol (main_name (), 0, VAR_DOMAIN, 0, NULL))
    ...

So this brings in full symbols for whatever compilation unit contains
'main'.  However, that symtab doesn't have a line 20, so the command
fails.

When we type 'break 10', main's symtab does have a line 10, so we
succeed.  However, we then call expand_line_sal (added as part of
Vlad's new multi-location breakpoint code), which reads in full
symbols for all partial symbol tables with the given name ---
including the one that does have a line 20.

Thus, when we type 'break 20' the second time, the loop in
find_line_symtab does have a second symtab to search, and the search
succeeds.

As for the fix, it seems to me that if find_line_symtab can't find a
match in the symtabs currently loaded, it should expand partial symbol
tables with the same name as the given symtab one by one until it
either finds one that does have the line we're looking for, or it runs
out of plausible psymtabs to try.

Even when find_line_common does return a line number, if it sets
*exact_match is zero, I think find_line_symtab should proceed to
expand psymtabs.  Otherwise, if the first symtab we happen to find has
line numbers higher than the one we're looking for, but some unread
symtab has an exact match, we'll just return the first line number in
the symtab we've got.

Re: DWARF question

[Carlos Eduardo Seo]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Jim Blandy wrote:
>
> I think I see the problem.  First, check this out:
>
>     (gdb) break 20
>     No line 20 in file "1s2c.c".
>     (gdb) break 10
>     Breakpoint 1 at 0x80483a1: file 1s2c.c, line 10.
>     (gdb) break 20
>     Breakpoint 2 at 0x80483c6: file 1s2c.c, line 20.
>     (gdb)
>
I can't reproduce this using my Fortran code:

    (gdb) b 31
    No line 31 in file "test-main.f".
    (gdb) b 25
    Breakpoint 1 at 0x10000670: file test-main.f, line 25.
    (gdb) b 31
    No line 31 in file "test-main.f".

But I know that line is there:

    (gdb) b ifunc
    Breakpoint 2 at 0x10000770: file test-main.f, line 30.

> As for the fix, it seems to me that if find_line_symtab can't find a
> match in the symtabs currently loaded, it should expand partial symbol
> tables with the same name as the given symtab one by one until it
> either finds one that does have the line we're looking for, or it runs
> out of plausible psymtabs to try.
>
> Even when find_line_common does return a line number, if it sets
> *exact_match is zero, I think find_line_symtab should proceed to
> expand psymtabs.  Otherwise, if the first symtab we happen to find has
> line numbers higher than the one we're looking for, but some unread
> symtab has an exact match, we'll just return the first line number in
> the symtab we've got.
Sounds reasonable to me. I'll try this.

Regards,

- --
Carlos Eduardo Seo
Software Engineer
IBM Linux Technology Center
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHAptaqvq7Aov/qQARAnZ7AKCDL8w1DdMqZzid7OzRAyvcoz+kWQCeOW37
JrS57mExOxzSTp6vi8N9iQg=
=6/rk
-----END PGP SIGNATURE-----

Re: DWARF question

[Carlos Eduardo Seo]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Jim Blandy wrote:
>
> As for the fix, it seems to me that if find_line_symtab can't find
> a match in the symtabs currently loaded, it should expand partial
> symbol tables with the same name as the given symtab one by one
> until it either finds one that does have the line we're looking
> for, or it runs out of plausible psymtabs to try.
>
> Even when find_line_common does return a line number, if it sets
> *exact_match is zero, I think find_line_symtab should proceed to
> expand psymtabs.  Otherwise, if the first symtab we happen to find
> has line numbers higher than the one we're looking for, but some
> unread symtab has an exact match, we'll just return the first line
> number in the symtab we've got.
I've written a patch and it worked:

    (gdb) b 25
    Breakpoint 1 at 0x10000670: file fxdb1251-main.f, line 25.
    (gdb) b 31
    Breakpoint 2 at 0x100007cc: file fxdb1251-main.f, line 31.

I'll post it here as soon as I finish my regression tests. Then we can
discuss if the solution is OK.

Regards,

- --
Carlos Eduardo Seo
Software Engineer
IBM Linux Technology Center
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHArt1qvq7Aov/qQARAtlhAKCArtkAFQuj4TEEMcXqwMv/K8IMJgCggWw3
Y3QsndBp5ksZxpDYsr7EAGQ=
=h56m
-----END PGP SIGNATURE-----

Re: DWARF question

[Carlos Eduardo Seo]

[-- Attachment #1: Type: text/plain, Size: 874 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1




Carlos Eduardo Seo wrote:
> 
> I've written a patch and it worked:
> 
>     (gdb) b 25
>     Breakpoint 1 at 0x10000670: file fxdb1251-main.f, line 25.
>     (gdb) b 31
>     Breakpoint 2 at 0x100007cc: file fxdb1251-main.f, line 31.
> 
> I'll post it here as soon as I finish my regression tests. Then we can
> discuss if the solution is OK.

Here's what I did. My testsuite run shows no regressions. I'm not sure
if this is the appropriate place to put the psymtab sweep, though. What
do you think?

- --
Carlos Eduardo Seo
Software Engineer
IBM Linux Technology Center
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHAs69qvq7Aov/qQARAse2AJ44Clae3J1eHr1bywraxOCmJ2LmzACeP6sv
uWnFk7mzAcxTeHIi3kDaRlo=
=lxnr
-----END PGP SIGNATURE-----

[-- Attachment #2: expand-psymtabs.diff --]
[-- Type: text/x-patch, Size: 777 bytes --]

2007-09-23  Carlos Eduardo Seo  <cseo@linux.vnet.ibm.com>

        * symtab.c (find_line_symtab): scan through psymtabs
	when exact_match is zero.


Index: src/gdb/symtab.c
===================================================================
--- src.orig/gdb/symtab.c
+++ src/gdb/symtab.c
@@ -2280,12 +2280,20 @@ find_line_symtab (struct symtab *symtab,
 
       struct objfile *objfile;
       struct symtab *s;
+      struct partial_symtab *p;
 
       if (best_index >= 0)
 	best = best_linetable->item[best_index].line;
       else
 	best = 0;
 
+      ALL_PSYMTABS (objfile, p)
+      {
+        if (strcmp (symtab->filename, p->filename) != 0)
+          continue;
+        PSYMTAB_TO_SYMTAB (p);
+      }
+
       ALL_SYMTABS (objfile, s)
       {
 	struct linetable *l;

[-- Attachment #3: expand-psymtabs.diff.sig --]
[-- Type: application/octet-stream, Size: 65 bytes --]

Re: DWARF question

[Jim Blandy]

Carlos Eduardo Seo <cseo at linux.vnet.ibm.com> writes:
> Jim Blandy wrote:
>>
>> What probably happens is that '-readnow' somehow affects the order in
>> which the full symtabs get put in the list.  I'm surprised that
>> breakpoints by line number in both main and the function work, but I
>> guess that has something to do with the nature of the bug in
>> find_line_symtab.
> Here's what I got. The loop  'ALL_SYMTABS' has only one iteration
> because 's->next' is NULL. So it seems that GDB isn't loading the
> other symtab.
>
> When I use '-readnow', both symtabs are there:
>
> (top-gdb) p s->filename
> $6 = 0x106a4930 "init.c"
> (top-gdb) p (s->next)->filename
> $7 = 0x1069cf10 "/usr/src/packages/BUILD/glibc-2.4/cc-nptl/csu/crti.S"
> (top-gdb) p ((s->next)->next)->filename
> $8 = 0x1069cc60 "test-main.f"
> (top-gdb) p (((s->next)->next)->next)->filename
> $9 = 0x1069c280 "test-main.f"
> (top-gdb) p ((((s->next)->next)->next)->next)->filename
> $10 = 0x1068d5c0 "crtsavres.S"
> (top-gdb) p (((((s->next)->next)->next)->next)->next)->filename
> $11 = 0x1068d2a0 "/usr/src/packages/BUILD/glibc-2.4/cc-nptl/csu/crtn.S"
> (top-gdb) p (((((s->next)->next)->next)->next)->next)->next
> $17 = (struct symtab *) 0x0

By the way, you might want to try using 'maint info symtabs' and
'maint info psymtabs'.  You can give it a regexp to restrict the
symtabs it lists.  It gives you expressions you can copy and paste
into the GDB debugging GDB if you want to look into something in more
detail.

Re: DWARF question

[Jim Blandy]

This one's fun, and demonstrates the 'exact_match' lossage I was
concerned about before.  Take a look at where two successive 'break 9'
commands set the breakpoints.  (Having three CUs didn't turn out to be
important; you could get the same effect without 'bar'.)

  $ cat 1s3c.mk
  CFLAGS = -g
  CC = gcc

  all: 1s3c

  1s3c: 1s3cFOO.o 1s3cMAIN.o 1s3cBAR.o
          $(CC) $(CFLAGS) $(LDFLAGS) $^ -o $@

  1s3c%.o: 1s3c.c
          $(CC) $(CFLAGS) $(CPPFLAGS) -D$* -c $< -o $@

  clean:
          rm -f 1s3c 1s3c*.o
  $ cat 1s3c.c
  #include <stdio.h>

  extern void foo (void);

  #ifdef FOO
  void
  foo (void)
  {
    puts ("foo");
  }
  #endif

  #ifdef MAIN
  int
  main (int argc, char **argv)
  {
    puts ("main");
    foo ();
    puts ("main again");
    bar ();
    puts ("main yet again");
    return 0;
  }
  #endif

  #ifdef BAR
  void
  bar (void)
  {
    puts ("foo");
  }
  #endif
  $ ~/gdb/pub/nat/gdb/gdb 1s3c
  GNU gdb 6.7.50-20070924-cvs
  Copyright (C) 2007 Free Software Foundation, Inc.
  License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
  This is free software: you are free to change and redistribute it.
  There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
  and "show warranty" for details.
  This GDB was configured as "i686-pc-linux-gnu"...
  Using host libthread_db library "/lib/libthread_db.so.1".
  (gdb) break 9
  Breakpoint 1 at 0x8048398: file 1s3c.c, line 9.
  (gdb) break 9
  Breakpoint 2 at 0x804838a: file 1s3c.c, line 9.
  (gdb) info breakpoints 
  Num     Type           Disp Enb  Address    What
  1       breakpoint     keep y    0x08048398 in main at 1s3c.c:9
  2       breakpoint     keep y    0x0804838a in foo at 1s3c.c:9
  (gdb)