how to access show/set data

how to access show/set data

[Kris Warkentin]

Say, for example, I wanted to programmatically modify solib_search_path, a
static char * which is declared in solib.c.

I know a pointer to it has been stored via the add_set_cmd function and I'm
wondering if there is a "approved" way for me to dig out this pointer.  I
have an OS dependent init file that needs to monkey with solib_search_path
and I didn't want to make the mods to solib.c or to make a "qnx_solib.c" for
such a small thing.

cheers,

Kris

Re: how to access show/set data

[Kris Warkentin]

Nevermind.  I found lookup_cmd().

cheers,

Kris

----- Original Message -----
From: "Kris Warkentin" <kewarken@qnx.com>
To: <gdb@sources.redhat.com>
Sent: Thursday, January 02, 2003 2:44 PM
Subject: how to access show/set data


> Say, for example, I wanted to programmatically modify solib_search_path, a
> static char * which is declared in solib.c.
>
> I know a pointer to it has been stored via the add_set_cmd function and
I'm
> wondering if there is a "approved" way for me to dig out this pointer.  I
> have an OS dependent init file that needs to monkey with solib_search_path
> and I didn't want to make the mods to solib.c or to make a "qnx_solib.c"
for
> such a small thing.
>
> cheers,
>
> Kris
>
>

GDB 5.2/5.3 breakpoint bug

[Sunil Alankar]

Hi,

 Attempting to set a class member function breakpoint (say break
myClass::funcOne) fails to set a proper break point in solaris 2.7.
This happens with GDB 5.2 and 5.3. Bug does not occur in GDB 5.1. Anybody
has any idea where to look?. I would appreciate any help.

Thx

Sunil

Re: GDB 5.2/5.3 breakpoint bug

[Daniel Jacobowitz]

On Fri, Jan 03, 2003 at 06:15:26PM -0800, Sunil Alankar wrote:
> Hi,
> 
>  Attempting to set a class member function breakpoint (say break
> myClass::funcOne) fails to set a proper break point in solaris 2.7.
> This happens with GDB 5.2 and 5.3. Bug does not occur in GDB 5.1. Anybody
> has any idea where to look?. I would appreciate any help.

What _does_ happen if it isn't a proper breakpoint?  Can you provide a
transcript?

What version of what compiler are you using?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: how to access show/set data

[Kevin Buettner]

On Jan 2,  2:44pm, Kris Warkentin wrote:

> Say, for example, I wanted to programmatically modify solib_search_path, a
> static char * which is declared in solib.c.
> 
> I know a pointer to it has been stored via the add_set_cmd function and I'm
> wondering if there is a "approved" way for me to dig out this pointer.  I
> have an OS dependent init file that needs to monkey with solib_search_path
> and I didn't want to make the mods to solib.c or to make a "qnx_solib.c" for
> such a small thing.

Why not just put set solib-search-path in your .gdbinit file?

(I don't know of any "approved" way of digging out the pointer.)

Kevin

Re: how to access show/set data

[Kris Warkentin]

Actually, I had replied to my own post (you must have missed it) but the
lookup_cmd() function in cli-decode.c does the trick nicely.  The reason we
don't use .gdbinit is because we ship our tools in an odd set of places
(depending on which host) and it's easier to have defaults than to force
customers to use a .gdbinit.  Besides, where do you put your gdbinit on a
windows host? ;-)

cheers,

Kris

----- Original Message -----
From: "Kevin Buettner" <kevinb@redhat.com>
To: "Kris Warkentin" <kewarken@qnx.com>; <gdb@sources.redhat.com>
Sent: Wednesday, January 08, 2003 6:15 PM
Subject: Re: how to access show/set data


> On Jan 2,  2:44pm, Kris Warkentin wrote:
>
> > Say, for example, I wanted to programmatically modify solib_search_path,
a
> > static char * which is declared in solib.c.
> >
> > I know a pointer to it has been stored via the add_set_cmd function and
I'm
> > wondering if there is a "approved" way for me to dig out this pointer.
I
> > have an OS dependent init file that needs to monkey with
solib_search_path
> > and I didn't want to make the mods to solib.c or to make a "qnx_solib.c"
for
> > such a small thing.
>
> Why not just put set solib-search-path in your .gdbinit file?
>
> (I don't know of any "approved" way of digging out the pointer.)
>
> Kevin
>

Re: how to access show/set data

[Christopher Faylor]

On Thu, Jan 09, 2003 at 08:32:15AM -0500, Kris Warkentin wrote:
>Besides, where do you put your gdbinit on a windows host?  ;-)

In your home directory, same as UNIX.

cgf

Re: how to access show/set data

[Kris Warkentin]

Not quite that simple.  If I have to provide a .gdbinit file for EVERY user
in order for gdb to properly find our libs, how do I write an installer that
does the right thing?  Some users might use Cygwin, some might not.  $HOME
might be set, it might not.  If I'm installing to Solaris or Linux, which
user accounts do I install a .gdbinit in?  It's non-trivial, especially when
you ship tools where various cpu targets have their libs in
$QNX_TARGET/$CPU/lib, and so on.  We ship gdb targetting 5 different CPU's
(arm, mips, powerpc, sh, i386) on 4 different hosts (QNX, Solaris, Linux and
Windows) so having a routine that programmatically sets up some defaults for
where host and target files are is the only sensible way to go.

Either way, I found a nice clean way to do it so I'm happy.  By the way, one
my coworkers wrote a very small enhancement to the .gdbinit code that I
would like to submit.  Basically it allows a backend writer to define
EXTRA_GDBINIT_FILENAME to a string which will be pre-pended to .gdbinit for
initial sourcing.  ie. We define it to be .ntoCPU-gdbinit and then if, for
instance, our x86 targetting gdb finds $HOME/.ntox86-gdbinit, it reads it
instead.  This is really handy for us because most of our development is
targetting remote machines so this way you can automatically connect to the
cpu target when you start gdb.  All you need then is 'source .gdbinit' at
the end of your cpu specific one and you can have specific and generic
sections for your init code.

Sorry about the patch (I just diffed it from CVS so you could take a look).
If you're interested in accepting this, I'll patch your CVS head branch and
submit a diff against that.

cheers,

Kris

Index: main.c
===================================================================
RCS file: /product/tools/gdb/gdb/main.c,v
retrieving revision 1.2
retrieving revision 1.3
diff -c -r1.2 -r1.3
*** main.c 6 Sep 2002 20:20:43 -0000 1.2
--- main.c 6 Sep 2002 21:23:46 -0000 1.3
***************
*** 524,534 ****
    homedir = getenv ("HOME");
    if (homedir)
      {
!       homeinit = (char *) alloca (strlen (homedir) +
!       strlen (gdbinit) + 10);
!       strcpy (homeinit, homedir);
!       strcat (homeinit, "/");
!       strcat (homeinit, gdbinit);

        if (!inhibit_gdbinit)
   {
--- 524,553 ----
    homedir = getenv ("HOME");
    if (homedir)
      {
!       /* Allow for a target specific gdbinit that will only override
!       the default gdbinit if it exists.  GP QNX Sep 6 2002 */
!       homeinit = 0;
!       if (extragdbinit)
!         {
!           homeinit = (char *) alloca (strlen (homedir) +
!                                       strlen (extragdbinit) + 10);
!
!           strcpy (homeinit, homedir);
!           strcat (homeinit, "/");
!           strcat (homeinit, extragdbinit);
!
!           if (stat (homeinit, &homebuf) < 0)
!               homeinit = 0;
!         }
!
!       if (!homeinit)
!         {
!           homeinit = (char *) alloca (strlen (homedir) +
!         strlen (gdbinit) + 10);
!           strcpy (homeinit, homedir);
!           strcat (homeinit, "/");
!           strcat (homeinit, gdbinit);
!         }

        if (!inhibit_gdbinit)
   {
Index: top.h
===================================================================
RCS file: /product/tools/gdb/gdb/top.h,v
retrieving revision 1.2
retrieving revision 1.3
diff -c -r1.2 -r1.3
*** top.h 6 Sep 2002 20:20:47 -0000 1.2
--- top.h 6 Sep 2002 21:23:46 -0000 1.3
***************
*** 30,35 ****
--- 30,36 ----
  extern int inhibit_gdbinit;
  extern int epoch_interface;
  extern char gdbinit[];
+ extern char *extragdbinit;

  extern void print_gdb_version (struct ui_file *);

Index: top.c
===================================================================
RCS file: /product/tools/gdb/gdb/top.c,v
retrieving revision 1.2
retrieving revision 1.3
diff -c -r1.2 -r1.3
*** top.c 6 Sep 2002 20:20:47 -0000 1.2
--- top.c 6 Sep 2002 21:23:46 -0000 1.3
***************
*** 76,81 ****
--- 76,87 ----
  #endif
  char gdbinit[] = GDBINIT_FILENAME;

+ #ifndef EXTRA_GDBINIT_FILENAME
+ #define EXTRA_GDBINIT_FILENAME 0
+ #endif
+
+ char *extragdbinit = EXTRA_GDBINIT_FILENAME;
+
  int inhibit_gdbinit = 0;

  /* If nonzero, and GDB has been configured to be able to use windows,

----- Original Message -----
From: "Christopher Faylor" <cgf@redhat.com>
To: <gdb@sources.redhat.com>
Sent: Thursday, January 09, 2003 1:21 PM
Subject: Re: how to access show/set data


> On Thu, Jan 09, 2003 at 08:32:15AM -0500, Kris Warkentin wrote:
> >Besides, where do you put your gdbinit on a windows host?  ;-)
>
> In your home directory, same as UNIX.
>
> cgf
>

Re: how to access show/set data

[Kris Warkentin]

> would like to submit.  Basically it allows a backend writer to define
> EXTRA_GDBINIT_FILENAME to a string which will be pre-pended to .gdbinit
for
> initial sourcing.  ie. We define it to be .ntoCPU-gdbinit and then if, for

Oops...not prepended.  Just defined.  Sorry.

Kris

Re: GDB 5.2/5.3 breakpoint bug

[Daniel Jacobowitz]

Sunil,

Try using "set language c++" before you try to set the breakpoint, and
let me know if that fixes it; I just built a Solaris GDB and verified
that it does for me.  This is a workaround for a real GDB bug and the
fix is still in progress; I hope it will be in 5.4.

On Wed, Jan 08, 2003 at 10:10:05AM -0800, Sunil Alankar wrote:
> Yes. GDB 5.1 sets break point on func() with the same binary/compiler. 5.2
> and 5.3 also work on Linux but have problems on Solaris.
> 
> --Sunil
> 
> -----Original Message-----
> From: Daniel Jacobowitz [mailto:drow@mvista.com]
> Sent: Wednesday, January 08, 2003 9:31 AM
> To: Sunil Alankar
> Cc: gdb@sources.redhat.com
> Subject: Re: GDB 5.2/5.3 breakpoint bug
> 
> 
> On Sun, Jan 05, 2003 at 03:07:04PM -0800, Sunil Alankar wrote:
> > //-------------------------------------------------------------
> > #include <systemc.h>
> >
> > SC_MODULE(top)
> > {
> >  public:
> >
> >     sc_in_clk iclk;
> >
> >     void func()
> >         {
> >             printf (".");
> >         }
> >
> >     SC_CTOR(top)
> >         {
> >             SC_METHOD(func);
> >             sensitive_pos << iclk;
> >             dont_initialize();
> >         }
> > };
> 
> 
> Func is an inline method.  Does gdb 5.1 really set a breakpoint on it?
> Using the exact same binary and compiler?  I find that pretty
> surprising, since there is no symbol for it anywhere; GDB's support for
> inline methods is pretty lousy right now.
> 
> --
> Daniel Jacobowitz
> MontaVista Software                         Debian GNU/Linux Developer
> 
> 

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: GDB 5.2/5.3 breakpoint bug

[Ching Lai]

Hi Daniel,

Thanks for the quick response and the patch.

Yes, the patch should fix the problem.  I made the same change
on my local copy of gdb 5.2.1 and it seems to work OK on my two test cases.

I reported the problem  in 11/25/02 to gdb bug report system with the bug
tracking number 849.

You should be able to close the bug.

Thanks again for your help.

Ching


      Reporter's email: ching@coware.com
      CC these people
      on PR status email:

      Number: 849
      Category: gdb
      Synopsis: no break line when stop at member function of a class
      Confidential: no
      Severity: serious
      Priority: medium
      Responsible: unassigned
      State: open
      Class: sw-bug
      Submitter-Id: net
      Arrival-Date: Mon Nov 25 10:08:03 PST 2002
      Closed-Date:
      Last-Modified:
      Originator: ching@coware.com
      Release: gdb5.2.1
      Organization:
      Environment: solaris 2.7

      Description: There is no break number displayed when you stop at
member function of a class for gdb5.2.1. It only happens in Solaris version
of gdb5.2.1. The linux version works OK. The previous
      version of solaris gdb 5.1 also works OK. So it must be something
change from 5.1  to 5.2.1. It seems to stop at the correctly location, but
just did not display the line number.
      /home/ching/testcase [tesla 6]>/eng-


----- Original Message -----
From: "Daniel Jacobowitz" <drow@mvista.com>
To: "Ching Lai" <ching@CoWare.com>
Cc: "Nafees" <nafees@CoWare.com>; <gdb@sources.redhat.com>; "Cesar Quiroz"
<Cesar.Quiroz@CoWare.com>; "Sunil Alankar" <salankar@CoWare.com>
Sent: Wednesday, January 08, 2003 7:40 PM
Subject: Re: GDB 5.2/5.3 breakpoint bug


> On Wed, Jan 08, 2003 at 02:45:23PM -0800, Ching Lai wrote:
> > Hi Daniel,
> >
> > > > Comment out the line 2753 in gdb 5.21 and 2777 in gdb  5.3 and build
> > them
> > > on
> > > > solaris seems to work OK with two test cases.
> > > >
> > > > Now the  question is to figure out why this line is added in gdb
5.21
> > and
> > > > gdb 5.3?
> > >
> > > The line is supposed to be there; it's so we know what is and isn't
> > > inside a function.  You need to explain better why it's causing a
> > > problem in find_pc_sect_line.
> >
> > The problem is the linetable in different symbol tables have the
> > same pc address in my testcase. One has valid number and the other one
> > with line number as 0 (which is added by the extra record_line()).
> >
> > In gdb 5.2.1 release of find_pc_set_line in symtab.c file.
> >
> >   1788        /* Is this file's best line closer than the best in the
other
> > files?
> >   1789           If so, record this file, and its best line, as best so
far.
> > */
> >   1790
> >   1791        if (prev && (!best || prev->pc > best->pc))
> >   1792          {
> >   1793            best = prev;
> >   1794            best_symtab = s;
> >   1795
> >   1796            /* Discard BEST_END if it's before the PC of the
current
> > BEST.  */
> >   1797            if (best_end <= best->pc)
> >   1798              best_end = 0;
> >   1799          }
> >
> > Since the line 1791 prev->pc with valid line number is not greater than
> > best->pc
> > which has 0 as line number, so it did not pick up the correct symbol
file.
> >
> > If the record_line is need in gdb 5.2.1 and gdb 5.3, then the line 1791
> > might
> > need an extra condition to void picking up the wrong symbol table which
has
> > line
> > number as 0 as added by record_line().
> >
> > 1791        if (prev && (!best || prev->pc > best->pc) && (prev->line !=
0))
> >
> >
> > Here are the debugging  section of my observation.
>
> Thanks for the extra detail.  I see what's going on now; I believe this
> patch should also avoid the problem.  Does it?
>
> --
> Daniel Jacobowitz
> MontaVista Software                         Debian GNU/Linux Developer
>
> 2002-03-08  Daniel Jacobowitz  <drow@mvista.com>
>
> * symtab.c (find_pc_sect_line): Don't consider end-of-function
> lines.
>
> Index: symtab.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/symtab.c,v
> retrieving revision 1.84
> diff -u -p -r1.84 symtab.c
> --- symtab.c 2 Jan 2003 14:27:26 -0000 1.84
> +++ symtab.c 9 Jan 2003 03:38:36 -0000
> @@ -2012,9 +2012,11 @@ find_pc_sect_line (CORE_ADDR pc, struct
>           the first line, prev will not be set.  */
>
>        /* Is this file's best line closer than the best in the other
files?
> -         If so, record this file, and its best line, as best so far.  */
> +         If so, record this file, and its best line, as best so far.
Don't
> +         save prev if it represents the end of a function (i.e. line
number
> +         0) instead of a real line.  */
>
> -      if (prev && (!best || prev->pc > best->pc))
> +      if (prev && prev->line && (!best || prev->pc > best->pc))
>   {
>     best = prev;
>     best_symtab = s;

Re: GDB 5.2/5.3 breakpoint bug

[Daniel Jacobowitz]

On Wed, Jan 08, 2003 at 02:45:23PM -0800, Ching Lai wrote:
> Hi Daniel,
> 
> > > Comment out the line 2753 in gdb 5.21 and 2777 in gdb  5.3 and build
> them
> > on
> > > solaris seems to work OK with two test cases.
> > >
> > > Now the  question is to figure out why this line is added in gdb 5.21
> and
> > > gdb 5.3?
> >
> > The line is supposed to be there; it's so we know what is and isn't
> > inside a function.  You need to explain better why it's causing a
> > problem in find_pc_sect_line.
> 
> The problem is the linetable in different symbol tables have the
> same pc address in my testcase. One has valid number and the other one
> with line number as 0 (which is added by the extra record_line()).
> 
> In gdb 5.2.1 release of find_pc_set_line in symtab.c file.
> 
>   1788        /* Is this file's best line closer than the best in the other
> files?
>   1789           If so, record this file, and its best line, as best so far.
> */
>   1790
>   1791        if (prev && (!best || prev->pc > best->pc))
>   1792          {
>   1793            best = prev;
>   1794            best_symtab = s;
>   1795
>   1796            /* Discard BEST_END if it's before the PC of the current
> BEST.  */
>   1797            if (best_end <= best->pc)
>   1798              best_end = 0;
>   1799          }
> 
> Since the line 1791 prev->pc with valid line number is not greater than
> best->pc
> which has 0 as line number, so it did not pick up the correct symbol file.
> 
> If the record_line is need in gdb 5.2.1 and gdb 5.3, then the line 1791
> might
> need an extra condition to void picking up the wrong symbol table which has
> line
> number as 0 as added by record_line().
> 
> 1791        if (prev && (!best || prev->pc > best->pc) && (prev->line != 0))
> 
> 
> Here are the debugging  section of my observation.

Thanks for the extra detail.  I see what's going on now; I believe this
patch should also avoid the problem.  Does it?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

2002-03-08  Daniel Jacobowitz  <drow@mvista.com>

	* symtab.c (find_pc_sect_line): Don't consider end-of-function
	lines.

Index: symtab.c
===================================================================
RCS file: /cvs/src/src/gdb/symtab.c,v
retrieving revision 1.84
diff -u -p -r1.84 symtab.c
--- symtab.c	2 Jan 2003 14:27:26 -0000	1.84
+++ symtab.c	9 Jan 2003 03:38:36 -0000
@@ -2012,9 +2012,11 @@ find_pc_sect_line (CORE_ADDR pc, struct 
          the first line, prev will not be set.  */
 
       /* Is this file's best line closer than the best in the other files?
-         If so, record this file, and its best line, as best so far.  */
+         If so, record this file, and its best line, as best so far.  Don't
+         save prev if it represents the end of a function (i.e. line number
+         0) instead of a real line.  */
 
-      if (prev && (!best || prev->pc > best->pc))
+      if (prev && prev->line && (!best || prev->pc > best->pc))
 	{
 	  best = prev;
 	  best_symtab = s;

Re: GDB 5.2/5.3 breakpoint bug

[Ching Lai]

Hi Daniel,

> > Comment out the line 2753 in gdb 5.21 and 2777 in gdb  5.3 and build
them
> on
> > solaris seems to work OK with two test cases.
> >
> > Now the  question is to figure out why this line is added in gdb 5.21
and
> > gdb 5.3?
>
> The line is supposed to be there; it's so we know what is and isn't
> inside a function.  You need to explain better why it's causing a
> problem in find_pc_sect_line.

The problem is the linetable in different symbol tables have the
same pc address in my testcase. One has valid number and the other one
with line number as 0 (which is added by the extra record_line()).

In gdb 5.2.1 release of find_pc_set_line in symtab.c file.

  1788        /* Is this file's best line closer than the best in the other
files?
  1789           If so, record this file, and its best line, as best so far.
*/
  1790
  1791        if (prev && (!best || prev->pc > best->pc))
  1792          {
  1793            best = prev;
  1794            best_symtab = s;
  1795
  1796            /* Discard BEST_END if it's before the PC of the current
BEST.  */
  1797            if (best_end <= best->pc)
  1798              best_end = 0;
  1799          }

Since the line 1791 prev->pc with valid line number is not greater than
best->pc
which has 0 as line number, so it did not pick up the correct symbol file.

If the record_line is need in gdb 5.2.1 and gdb 5.3, then the line 1791
might
need an extra condition to void picking up the wrong symbol table which has
line
number as 0 as added by record_line().

1791        if (prev && (!best || prev->pc > best->pc) && (prev->line != 0))


Here are the debugging  section of my observation.

db) x/320d &s->linetable.nitems
0x6debf0:       77      1667196020      3069    1667200366
0x6dec00:       0       1229376 3069    1701207922
....
0x6df080:       0       1231068 1224    0
0x6df090:       0       1231080 1226    0
0x6df0a0:       0       1231080 1228    0
0x6df0b0:       0       1231152 0       0
0x6df0c0:       0       1231160 0       0            <=================  pc
1231160 with line number 0 for sc_unsigned.h symbol
0x6df0d0:       0       0       795176551       762405167
0x6df0e0:       1667787118      1731159908      1647129902      841888046
gdb) p pc
$37 = 1231164   <========= pc that we are looking for line number of a
symbol
gdb) p s->filename
$38 = 0x6f54c0
"/eng-qa/ching/sv4.1/source/../release/solaris/tools/include/systemc/datatyp
es/int/sc_unsigned.h"
(gdb) p *s
$39 = {next = 0x6f53b0, blockvector = 0x6f4578, linetable = 0x6debf0,
block_line_section = 10, primary = 0, filename = 0x6f54c0 "/
eng-qa/ching/sv4.1/source/../release/solaris/tools/include/systemc/datatypes
/int/sc_unsigned.h", dirname = 0x6df0d8 "/eng-qa/ching
/gdb-5.2.1.inst/bin/", free_code = free_linetable, free_ptr = 0x0, nlines =
0, line_charpos = 0x0, language = language_cplus, debu
gformat = 0x6f5520 "unknown", version = 0x0, fullname = 0x0, objfile =
0x28ca98}

gdb) x/80d &s->linetable.nitems
0x6f4660:       14      0       8       0
0x6f4670:       0       114628  8       0
....
0x6f46f0:       0       114740  5       0
0x6f4700:       0       1231160 5       0    <=============== another pc
with the correct line number 5 for t.cpp symbol
0x6f4710:       0       1231168 6       0
0x6f4720:       0       1231184 7       0
0x6f4730:       0       1231192 0       0
0x6f4740:       0       1231200 0       0
0x6f4750:       0       0       795176551       762405167
0x6f4760:       1667787118      1731159908      1647129902      841888046
(gdb) p pc
$41 = 1231164

(gdb) p s->filename
$42 = 0x6f4630 "/eng-qa/ching/gdb-5.2.1.inst/bin/t.cpp"


Does this make sense?

Thanks.


Ching

----- Original Message -----
From: "Daniel Jacobowitz" <drow@mvista.com>
To: "Sunil Alankar" <sunil.alankar@CoWare.com>
Cc: <gdb@sources.redhat.com>
Sent: Wednesday, January 08, 2003 12:46 PM
Subject: Re: GDB 5.2/5.3 breakpoint bug


> On Wed, Jan 08, 2003 at 12:37:29PM -0800, Sunil Alankar wrote:
> > Meanwhile, a colleague of mine had a different workaround:
> >
> > There is one extra record_line call in gdb 5.21 and gdb 5.3 which
inserts
> > extra line number
> > and pc into the linetable of symtab entry.
> >
> > gdb/dbxread.c in gdb.5.1.01
> >   1919        if (*name == '\000')
> >   1920          {
> >   1921            /* This N_FUN marks the end of a function.  This
closes
> > off the
> >   1922               current block.  */
> >   1923            within_function = 0;
> >   1924            new = pop_context ();
> >
> > gdb/dbxread.c in gdb 5.2.1
> >   2749        if (*name == '\000')
> >   2750          {
> >   2751            /* This N_FUN marks the end of a function.  This
closes
> > off the
> >   2752               current block.  */
> >   2753            record_line (current_subfile, 0, function_start_offset
+
> > valu);
> >   2754            within_function = 0;
> >   2755            new = pop_context ();
> >   2756
> >
> > gdb/dbxread.c in gdb 5.3
> >
> >   2773        if (*name == '\000')
> >   2774          {
> >   2775            /* This N_FUN marks the end of a function.  This
closes
> > off the
> >   2776               current block.  */
> >   2777            record_line (current_subfile, 0, function_start_offset
+
> > valu);
> >   2778            within_function = 0;
> >   2779            new = pop_context ();
> >   2780
> >
> >
> > Comment out the line 2753 in gdb 5.21 and 2777 in gdb  5.3 and build
them
> on
> > solaris seems to work OK with two test cases.
> >
> > Now the  question is to figure out why this line is added in gdb 5.21
and
> > gdb 5.3?
>
> The line is supposed to be there; it's so we know what is and isn't
> inside a function.  You need to explain better why it's causing a
> problem in find_pc_sect_line.
>
> --
> Daniel Jacobowitz
> MontaVista Software                         Debian GNU/Linux Developer
>

Re: GDB 5.2/5.3 breakpoint bug

[Daniel Jacobowitz]

On Wed, Jan 08, 2003 at 12:37:29PM -0800, Sunil Alankar wrote:
> Meanwhile, a colleague of mine had a different workaround:
> 
> There is one extra record_line call in gdb 5.21 and gdb 5.3 which inserts
> extra line number
> and pc into the linetable of symtab entry.
> 
> gdb/dbxread.c in gdb.5.1.01
>   1919        if (*name == '\000')
>   1920          {
>   1921            /* This N_FUN marks the end of a function.  This closes
> off the
>   1922               current block.  */
>   1923            within_function = 0;
>   1924            new = pop_context ();
> 
> gdb/dbxread.c in gdb 5.2.1
>   2749        if (*name == '\000')
>   2750          {
>   2751            /* This N_FUN marks the end of a function.  This closes
> off the
>   2752               current block.  */
>   2753            record_line (current_subfile, 0, function_start_offset +
> valu);
>   2754            within_function = 0;
>   2755            new = pop_context ();
>   2756
> 
> gdb/dbxread.c in gdb 5.3
> 
>   2773        if (*name == '\000')
>   2774          {
>   2775            /* This N_FUN marks the end of a function.  This closes
> off the
>   2776               current block.  */
>   2777            record_line (current_subfile, 0, function_start_offset +
> valu);
>   2778            within_function = 0;
>   2779            new = pop_context ();
>   2780
> 
> 
> Comment out the line 2753 in gdb 5.21 and 2777 in gdb  5.3 and build them on
> solaris seems to work OK with two test cases.
> 
> Now the  question is to figure out why this line is added in gdb 5.21 and
> gdb 5.3?

The line is supposed to be there; it's so we know what is and isn't
inside a function.  You need to explain better why it's causing a
problem in find_pc_sect_line.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

RE: GDB 5.2/5.3 breakpoint bug

[Sunil Alankar]

Meanwhile, a colleague of mine had a different workaround:

There is one extra record_line call in gdb 5.21 and gdb 5.3 which inserts
extra line number
and pc into the linetable of symtab entry.

gdb/dbxread.c in gdb.5.1.01
  1919        if (*name == '\000')
  1920          {
  1921            /* This N_FUN marks the end of a function.  This closes
off the
  1922               current block.  */
  1923            within_function = 0;
  1924            new = pop_context ();

gdb/dbxread.c in gdb 5.2.1
  2749        if (*name == '\000')
  2750          {
  2751            /* This N_FUN marks the end of a function.  This closes
off the
  2752               current block.  */
  2753            record_line (current_subfile, 0, function_start_offset +
valu);
  2754            within_function = 0;
  2755            new = pop_context ();
  2756

gdb/dbxread.c in gdb 5.3

  2773        if (*name == '\000')
  2774          {
  2775            /* This N_FUN marks the end of a function.  This closes
off the
  2776               current block.  */
  2777            record_line (current_subfile, 0, function_start_offset +
valu);
  2778            within_function = 0;
  2779            new = pop_context ();
  2780


Comment out the line 2753 in gdb 5.21 and 2777 in gdb  5.3 and build them on
solaris seems to work OK with two test cases.

Now the  question is to figure out why this line is added in gdb 5.21 and
gdb 5.3?


Thx


Sunil

> -----Original Message-----
> From: gdb-owner@sources.redhat.com
> [mailto:gdb-owner@sources.redhat.com]On Behalf Of Sunil Alankar
> Sent: Wednesday, January 08, 2003 11:36 AM
> To: Daniel Jacobowitz
> Cc: gdb@sources.redhat.com
> Subject: RE: GDB 5.2/5.3 breakpoint bug
>
>
>
>
> -----Original Message-----
> From: Daniel Jacobowitz [mailto:drow@mvista.com]
> Sent: Wednesday, January 08, 2003 11:32 AM
> To: Sunil Alankar
> Cc: gdb@sources.redhat.com
> Subject: Re: GDB 5.2/5.3 breakpoint bug
>
>
> On Wed, Jan 08, 2003 at 11:15:59AM -0800, Sunil Alankar wrote:
> >
> >
> > -----Original Message-----
> > From: Daniel Jacobowitz [mailto:drow@mvista.com]
> > Sent: Wednesday, January 08, 2003 10:16 AM
> > To: Sunil Alankar; gdb@sources.redhat.com
> > Subject: Re: GDB 5.2/5.3 breakpoint bug
> >
> >
> > On Wed, Jan 08, 2003 at 12:39:31PM -0500, Daniel Jacobowitz wrote:
> > > On Tue, Jan 07, 2003 at 03:49:31PM -0800, Sunil Alankar wrote:
> > > > Hi,
> > > >
> > > > While debugging this in function, find_pc_sect_line (CORE_ADDR pc,
> > struct
> > > > sec *section, int notcurrent)
> > > > I found there were two line items in a line table with the
> same value
> of
> > PC.
> > > > First one gets picked as the best match. But this had
> item->line == 0.
> > The
> > > > next line item with the same value for item->pc, but a valid
> item->line
> > ( >
> > > > 0) does not get picked as the best match.
> > > > I put in the following check to correct this. My question is,
> > > > Is it valid to have have more than one line item with same
> value faor
> PC
> > and
> > > > possibly 0 for line in one of them? What causes this?
> > > > Would this be an appropriate fix? Or is the problem more deep rooted
> in
> > > > creating the symbol table?
> > >
> > > When this happens, are the two lines in different files?
> >
> > I just can't get this to happen.  If two items in a row have the same
> > PC, we should never be picking the first of the two.
> >
> >
> > I see two entries with the same PC in a line table. Wonder if
> the problem
> is
> > in creation of the symbol table itself?
>
> Two entries with the same PC is not the problem; that's expected.
> Choosing the first is a problem; I can't get the code to do that.  I'll
> look at what you sent me.
>
> > I came across another problem which may be related. In the following
> > example, with gdb 5.3 on solaris:
> >
> >
> >  //-------------------------------------------------------------
> >  #include <systemc.h>
> >
> >  SC_MODULE(top)
> > {
> >   public:
> >
> >      sc_in_clk iclk;
> >
> >      void func()
> >          {
> >              printf (".");
> >          }
> >
> >      SC_CTOR(top)
> >          {
> >              SC_METHOD(func);
> >              sensitive_pos << iclk;
> >              dont_initialize();
> >          }
> > };
> >
> > //--------------------------------------------------------------
> >
> > (gdb) b top::func
> > the class top does not have any method named func
> > Hint: try 'top::func<TAB> or 'top::func<ESC-?>
> > (Note leading single quote.)
> > (gdb) b top::func(void)
> > Breakpoint 1 at 0x1333a8       <<<<< incorrectly set
> >
> >
> > There are two problems.
> > 1. GDB can not set the bp without specifying the full signature.
>
> If you specify the full signature it uses a different search technique;
> that's much more likely to work.  This is still a bug.
>
> > 2. Break point is incorrect even after specifying the full signature.
> >
> > Problem 2 goes away with my earlier workaround in gdb code.
>
> We need to figure out why this is happening.
>
>
> > While investigating problem 1, I found some mismatches in the scanning
> > functions in symtab.c.
> >
> > lookup_block_symbol (register const struct block *block, const
> char *name,
> > 		     const char *mangled_name,
> > 		     const namespace_enum namespace)
> > {
> > ............
> >  if (BLOCK_HASHTABLE (block))
> >     {
> >       unsigned int hash_index;
> >       hash_index = msymbol_hash_iw (name);
> >       hash_index = hash_index % BLOCK_BUCKETS (block);
> >
> >       //<<<<< at this point I get a nr of buckets in the table 17,
> > hash_index of 13 for the name
> > 	//<<<<< We only search in the bucket of index 13
> > 	//<<<<< when I manually instrumented and inspected the
> > 	//<<<<< block table, the required symbol (func__3top) is in
> the bucket 6
> > and we miss it.
>
> What are name and mangled_name?  I bet they're both func__3top.  This
> is a known bug and David's development branch contains a change which
> fixes it for this particular case; current_language is probably C when
> you start the search even though you're looking for a C++ symbol.
>
> I think the variable 'mangled_name' was null and 'name' was
> func__3top (for
> gdb command 'break top::func'). I would like to try the fix if
> there is one
> already.
>
> Thx
>
> Sunil
>
> --
> Daniel Jacobowitz
> MontaVista Software                         Debian GNU/Linux Developer
>

RE: GDB 5.2/5.3 breakpoint bug

[Sunil Alankar]

-----Original Message-----
From: Daniel Jacobowitz [mailto:drow@mvista.com]
Sent: Wednesday, January 08, 2003 11:32 AM
To: Sunil Alankar
Cc: gdb@sources.redhat.com
Subject: Re: GDB 5.2/5.3 breakpoint bug


On Wed, Jan 08, 2003 at 11:15:59AM -0800, Sunil Alankar wrote:
>
>
> -----Original Message-----
> From: Daniel Jacobowitz [mailto:drow@mvista.com]
> Sent: Wednesday, January 08, 2003 10:16 AM
> To: Sunil Alankar; gdb@sources.redhat.com
> Subject: Re: GDB 5.2/5.3 breakpoint bug
>
>
> On Wed, Jan 08, 2003 at 12:39:31PM -0500, Daniel Jacobowitz wrote:
> > On Tue, Jan 07, 2003 at 03:49:31PM -0800, Sunil Alankar wrote:
> > > Hi,
> > >
> > > While debugging this in function, find_pc_sect_line (CORE_ADDR pc,
> struct
> > > sec *section, int notcurrent)
> > > I found there were two line items in a line table with the same value
of
> PC.
> > > First one gets picked as the best match. But this had item->line == 0.
> The
> > > next line item with the same value for item->pc, but a valid
item->line
> ( >
> > > 0) does not get picked as the best match.
> > > I put in the following check to correct this. My question is,
> > > Is it valid to have have more than one line item with same value faor
PC
> and
> > > possibly 0 for line in one of them? What causes this?
> > > Would this be an appropriate fix? Or is the problem more deep rooted
in
> > > creating the symbol table?
> >
> > When this happens, are the two lines in different files?
>
> I just can't get this to happen.  If two items in a row have the same
> PC, we should never be picking the first of the two.
>
>
> I see two entries with the same PC in a line table. Wonder if the problem
is
> in creation of the symbol table itself?

Two entries with the same PC is not the problem; that's expected.
Choosing the first is a problem; I can't get the code to do that.  I'll
look at what you sent me.

> I came across another problem which may be related. In the following
> example, with gdb 5.3 on solaris:
>
>
>  //-------------------------------------------------------------
>  #include <systemc.h>
>
>  SC_MODULE(top)
> {
>   public:
>
>      sc_in_clk iclk;
>
>      void func()
>          {
>              printf (".");
>          }
>
>      SC_CTOR(top)
>          {
>              SC_METHOD(func);
>              sensitive_pos << iclk;
>              dont_initialize();
>          }
> };
>
> //--------------------------------------------------------------
>
> (gdb) b top::func
> the class top does not have any method named func
> Hint: try 'top::func<TAB> or 'top::func<ESC-?>
> (Note leading single quote.)
> (gdb) b top::func(void)
> Breakpoint 1 at 0x1333a8       <<<<< incorrectly set
>
>
> There are two problems.
> 1. GDB can not set the bp without specifying the full signature.

If you specify the full signature it uses a different search technique;
that's much more likely to work.  This is still a bug.

> 2. Break point is incorrect even after specifying the full signature.
>
> Problem 2 goes away with my earlier workaround in gdb code.

We need to figure out why this is happening.


> While investigating problem 1, I found some mismatches in the scanning
> functions in symtab.c.
>
> lookup_block_symbol (register const struct block *block, const char *name,
> 		     const char *mangled_name,
> 		     const namespace_enum namespace)
> {
> ............
>  if (BLOCK_HASHTABLE (block))
>     {
>       unsigned int hash_index;
>       hash_index = msymbol_hash_iw (name);
>       hash_index = hash_index % BLOCK_BUCKETS (block);
>
>       //<<<<< at this point I get a nr of buckets in the table 17,
> hash_index of 13 for the name
> 	//<<<<< We only search in the bucket of index 13
> 	//<<<<< when I manually instrumented and inspected the
> 	//<<<<< block table, the required symbol (func__3top) is in the bucket 6
> and we miss it.

What are name and mangled_name?  I bet they're both func__3top.  This
is a known bug and David's development branch contains a change which
fixes it for this particular case; current_language is probably C when
you start the search even though you're looking for a C++ symbol.

I think the variable 'mangled_name' was null and 'name' was func__3top (for
gdb command 'break top::func'). I would like to try the fix if there is one
already.

Thx

Sunil

--
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: GDB 5.2/5.3 breakpoint bug

[Daniel Jacobowitz]

On Wed, Jan 08, 2003 at 11:15:59AM -0800, Sunil Alankar wrote:
> 
> 
> -----Original Message-----
> From: Daniel Jacobowitz [mailto:drow@mvista.com]
> Sent: Wednesday, January 08, 2003 10:16 AM
> To: Sunil Alankar; gdb@sources.redhat.com
> Subject: Re: GDB 5.2/5.3 breakpoint bug
> 
> 
> On Wed, Jan 08, 2003 at 12:39:31PM -0500, Daniel Jacobowitz wrote:
> > On Tue, Jan 07, 2003 at 03:49:31PM -0800, Sunil Alankar wrote:
> > > Hi,
> > >
> > > While debugging this in function, find_pc_sect_line (CORE_ADDR pc,
> struct
> > > sec *section, int notcurrent)
> > > I found there were two line items in a line table with the same value of
> PC.
> > > First one gets picked as the best match. But this had item->line == 0.
> The
> > > next line item with the same value for item->pc, but a valid item->line
> ( >
> > > 0) does not get picked as the best match.
> > > I put in the following check to correct this. My question is,
> > > Is it valid to have have more than one line item with same value faor PC
> and
> > > possibly 0 for line in one of them? What causes this?
> > > Would this be an appropriate fix? Or is the problem more deep rooted in
> > > creating the symbol table?
> >
> > When this happens, are the two lines in different files?
> 
> I just can't get this to happen.  If two items in a row have the same
> PC, we should never be picking the first of the two.
> 
> 
> I see two entries with the same PC in a line table. Wonder if the problem is
> in creation of the symbol table itself?

Two entries with the same PC is not the problem; that's expected. 
Choosing the first is a problem; I can't get the code to do that.  I'll
look at what you sent me.

> I came across another problem which may be related. In the following
> example, with gdb 5.3 on solaris:
> 
> 
>  //-------------------------------------------------------------
>  #include <systemc.h>
> 
>  SC_MODULE(top)
> {
>   public:
> 
>      sc_in_clk iclk;
> 
>      void func()
>          {
>              printf (".");
>          }
> 
>      SC_CTOR(top)
>          {
>              SC_METHOD(func);
>              sensitive_pos << iclk;
>              dont_initialize();
>          }
> };
> 
> //--------------------------------------------------------------
> 
> (gdb) b top::func
> the class top does not have any method named func
> Hint: try 'top::func<TAB> or 'top::func<ESC-?>
> (Note leading single quote.)
> (gdb) b top::func(void)
> Breakpoint 1 at 0x1333a8       <<<<< incorrectly set
> 
> 
> There are two problems.
> 1. GDB can not set the bp without specifying the full signature.

If you specify the full signature it uses a different search technique;
that's much more likely to work.  This is still a bug.

> 2. Break point is incorrect even after specifying the full signature.
> 
> Problem 2 goes away with my earlier workaround in gdb code.

We need to figure out why this is happening.


> While investigating problem 1, I found some mismatches in the scanning
> functions in symtab.c.
> 
> lookup_block_symbol (register const struct block *block, const char *name,
> 		     const char *mangled_name,
> 		     const namespace_enum namespace)
> {
> ............
>  if (BLOCK_HASHTABLE (block))
>     {
>       unsigned int hash_index;
>       hash_index = msymbol_hash_iw (name);
>       hash_index = hash_index % BLOCK_BUCKETS (block);
> 
>       //<<<<< at this point I get a nr of buckets in the table 17,
> hash_index of 13 for the name
> 	//<<<<< We only search in the bucket of index 13
> 	//<<<<< when I manually instrumented and inspected the
> 	//<<<<< block table, the required symbol (func__3top) is in the bucket 6
> and we miss it.

What are name and mangled_name?  I bet they're both func__3top.  This
is a known bug and David's development branch contains a change which
fixes it for this particular case; current_language is probably C when
you start the search even though you're looking for a C++ symbol.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

RE: GDB 5.2/5.3 breakpoint bug

[Sunil Alankar]

-----Original Message-----
From: Daniel Jacobowitz [mailto:drow@mvista.com]
Sent: Wednesday, January 08, 2003 10:16 AM
To: Sunil Alankar; gdb@sources.redhat.com
Subject: Re: GDB 5.2/5.3 breakpoint bug


On Wed, Jan 08, 2003 at 12:39:31PM -0500, Daniel Jacobowitz wrote:
> On Tue, Jan 07, 2003 at 03:49:31PM -0800, Sunil Alankar wrote:
> > Hi,
> >
> > While debugging this in function, find_pc_sect_line (CORE_ADDR pc,
struct
> > sec *section, int notcurrent)
> > I found there were two line items in a line table with the same value of
PC.
> > First one gets picked as the best match. But this had item->line == 0.
The
> > next line item with the same value for item->pc, but a valid item->line
( >
> > 0) does not get picked as the best match.
> > I put in the following check to correct this. My question is,
> > Is it valid to have have more than one line item with same value faor PC
and
> > possibly 0 for line in one of them? What causes this?
> > Would this be an appropriate fix? Or is the problem more deep rooted in
> > creating the symbol table?
>
> When this happens, are the two lines in different files?

I just can't get this to happen.  If two items in a row have the same
PC, we should never be picking the first of the two.


I see two entries with the same PC in a line table. Wonder if the problem is
in creation of the symbol table itself?
I came across another problem which may be related. In the following
example, with gdb 5.3 on solaris:


 //-------------------------------------------------------------
 #include <systemc.h>

 SC_MODULE(top)
{
  public:

     sc_in_clk iclk;

     void func()
         {
             printf (".");
         }

     SC_CTOR(top)
         {
             SC_METHOD(func);
             sensitive_pos << iclk;
             dont_initialize();
         }
};

//--------------------------------------------------------------

(gdb) b top::func
the class top does not have any method named func
Hint: try 'top::func<TAB> or 'top::func<ESC-?>
(Note leading single quote.)
(gdb) b top::func(void)
Breakpoint 1 at 0x1333a8       <<<<< incorrectly set


There are two problems.
1. GDB can not set the bp without specifying the full signature.
2. Break point is incorrect even after specifying the full signature.

Problem 2 goes away with my earlier workaround in gdb code.

While investigating problem 1, I found some mismatches in the scanning
functions in symtab.c.

lookup_block_symbol (register const struct block *block, const char *name,
		     const char *mangled_name,
		     const namespace_enum namespace)
{
............
 if (BLOCK_HASHTABLE (block))
    {
      unsigned int hash_index;
      hash_index = msymbol_hash_iw (name);
      hash_index = hash_index % BLOCK_BUCKETS (block);

      //<<<<< at this point I get a nr of buckets in the table 17,
hash_index of 13 for the name
	//<<<<< We only search in the bucket of index 13
	//<<<<< when I manually instrumented and inspected the
	//<<<<< block table, the required symbol (func__3top) is in the bucket 6
and we miss it.

      for (sym = BLOCK_BUCKET (block, hash_index); sym; sym =
sym->hash_next)
	{
	    if (SYMBOL_DEMANGLED_NAME(sym))
	  if (SYMBOL_NAMESPACE (sym) == namespace
	      && (mangled_name
		  ? strcmp (SYMBOL_NAME (sym), mangled_name) == 0
		  : SYMBOL_MATCHES_NAME (sym, name)))
	  {
	      if (SYMBOL_DEMANGLED_NAME(sym))
	      return sym;
	  }

	}
      return NULL;
    }

...................
}

Any thoughts?
Thx

Sunil

Re: GDB 5.2/5.3 breakpoint bug

[Daniel Jacobowitz]

I don't have access to Solaris, and I can't see how this would work;
can you send me (privately) a compiled binary that GDB 5.1 can insert
the breakpoint in?

On Wed, Jan 08, 2003 at 10:10:05AM -0800, Sunil Alankar wrote:
> Yes. GDB 5.1 sets break point on func() with the same binary/compiler. 5.2
> and 5.3 also work on Linux but have problems on Solaris.
> 
> --Sunil
> 
> -----Original Message-----
> From: Daniel Jacobowitz [mailto:drow@mvista.com]
> Sent: Wednesday, January 08, 2003 9:31 AM
> To: Sunil Alankar
> Cc: gdb@sources.redhat.com
> Subject: Re: GDB 5.2/5.3 breakpoint bug
> 
> 
> On Sun, Jan 05, 2003 at 03:07:04PM -0800, Sunil Alankar wrote:
> > //-------------------------------------------------------------
> > #include <systemc.h>
> >
> > SC_MODULE(top)
> > {
> >  public:
> >
> >     sc_in_clk iclk;
> >
> >     void func()
> >         {
> >             printf (".");
> >         }
> >
> >     SC_CTOR(top)
> >         {
> >             SC_METHOD(func);
> >             sensitive_pos << iclk;
> >             dont_initialize();
> >         }
> > };
> 
> 
> Func is an inline method.  Does gdb 5.1 really set a breakpoint on it?
> Using the exact same binary and compiler?  I find that pretty
> surprising, since there is no symbol for it anywhere; GDB's support for
> inline methods is pretty lousy right now.
> 
> --
> Daniel Jacobowitz
> MontaVista Software                         Debian GNU/Linux Developer
> 
> 

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: GDB 5.2/5.3 breakpoint bug

[Daniel Jacobowitz]

On Wed, Jan 08, 2003 at 12:39:31PM -0500, Daniel Jacobowitz wrote:
> On Tue, Jan 07, 2003 at 03:49:31PM -0800, Sunil Alankar wrote:
> > Hi,
> > 
> > While debugging this in function, find_pc_sect_line (CORE_ADDR pc, struct
> > sec *section, int notcurrent)
> > I found there were two line items in a line table with the same value of PC.
> > First one gets picked as the best match. But this had item->line == 0. The
> > next line item with the same value for item->pc, but a valid item->line ( >
> > 0) does not get picked as the best match.
> > I put in the following check to correct this. My question is,
> > Is it valid to have have more than one line item with same value faor PC and
> > possibly 0 for line in one of them? What causes this?
> > Would this be an appropriate fix? Or is the problem more deep rooted in
> > creating the symbol table?
> 
> When this happens, are the two lines in different files?

I just can't get this to happen.  If two items in a row have the same
PC, we should never be picking the first of the two.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

RE: GDB 5.2/5.3 breakpoint bug

[Sunil Alankar]

Yes. GDB 5.1 sets break point on func() with the same binary/compiler. 5.2
and 5.3 also work on Linux but have problems on Solaris.

--Sunil

-----Original Message-----
From: Daniel Jacobowitz [mailto:drow@mvista.com]
Sent: Wednesday, January 08, 2003 9:31 AM
To: Sunil Alankar
Cc: gdb@sources.redhat.com
Subject: Re: GDB 5.2/5.3 breakpoint bug


On Sun, Jan 05, 2003 at 03:07:04PM -0800, Sunil Alankar wrote:
> //-------------------------------------------------------------
> #include <systemc.h>
>
> SC_MODULE(top)
> {
>  public:
>
>     sc_in_clk iclk;
>
>     void func()
>         {
>             printf (".");
>         }
>
>     SC_CTOR(top)
>         {
>             SC_METHOD(func);
>             sensitive_pos << iclk;
>             dont_initialize();
>         }
> };


Func is an inline method.  Does gdb 5.1 really set a breakpoint on it?
Using the exact same binary and compiler?  I find that pretty
surprising, since there is no symbol for it anywhere; GDB's support for
inline methods is pretty lousy right now.

--
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: GDB 5.2/5.3 breakpoint bug

[Daniel Jacobowitz]

On Tue, Jan 07, 2003 at 03:49:31PM -0800, Sunil Alankar wrote:
> Hi,
> 
> While debugging this in function, find_pc_sect_line (CORE_ADDR pc, struct
> sec *section, int notcurrent)
> I found there were two line items in a line table with the same value of PC.
> First one gets picked as the best match. But this had item->line == 0. The
> next line item with the same value for item->pc, but a valid item->line ( >
> 0) does not get picked as the best match.
> I put in the following check to correct this. My question is,
> Is it valid to have have more than one line item with same value faor PC and
> possibly 0 for line in one of them? What causes this?
> Would this be an appropriate fix? Or is the problem more deep rooted in
> creating the symbol table?

When this happens, are the two lines in different files?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: GDB 5.2/5.3 breakpoint bug

[Daniel Jacobowitz]

On Sun, Jan 05, 2003 at 03:07:04PM -0800, Sunil Alankar wrote:
> //-------------------------------------------------------------
> #include <systemc.h>
> 
> SC_MODULE(top)
> {
>  public:
> 
>     sc_in_clk iclk;
> 
>     void func()
>         {
>             printf (".");
>         }
> 
>     SC_CTOR(top)
>         {
>             SC_METHOD(func);
>             sensitive_pos << iclk;
>             dont_initialize();
>         }
> };


Func is an inline method.  Does gdb 5.1 really set a breakpoint on it? 
Using the exact same binary and compiler?  I find that pretty
surprising, since there is no symbol for it anywhere; GDB's support for
inline methods is pretty lousy right now.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: GDB 5.2/5.3 breakpoint bug

[Daniel Jacobowitz]

On Tue, Jan 07, 2003 at 03:49:31PM -0800, Sunil Alankar wrote:
> Hi,
> 
> While debugging this in function, find_pc_sect_line (CORE_ADDR pc, struct
> sec *section, int notcurrent)
> I found there were two line items in a line table with the same value of PC.
> First one gets picked as the best match. But this had item->line == 0. The
> next line item with the same value for item->pc, but a valid item->line ( >
> 0) does not get picked as the best match.
> I put in the following check to correct this. My question is,
> Is it valid to have have more than one line item with same value faor PC and
> possibly 0 for line in one of them? What causes this?
> Would this be an appropriate fix? Or is the problem more deep rooted in
> creating the symbol table?

I'll look at this more precisely later (tomorrow, I hope...) but what
that means is that a function ends exactly where another one starts. 
Very interesting; we probably should ignore the ending marker in that
case, but I'm not sure you're doing it the best way.

> 
> --- ../original/gdb-5.3/gdb/symtab.c       Thu Aug 29 20:24:00 2002
> +++ gdb-5.3/gdb/symtab.c        Tue Jan  7 14:42:34 2003
> @@ -1950,6 +1950,21 @@
>             best_end = 0;
>         }
> 
> +      /* Handle the case where the prev->pc == best->pc due to more than
> one line
> +        items for a pc, but the best->line == 0. grab a better match if one
> exists
> +        that has a non zero line number  */
> +
> +      else if (prev && (!best || ((prev->pc == best->pc) && (best->line ==
> 0)
> +                                 && (prev->line != 0))))
> +       {
> +         best = prev;
> +         best_symtab = s;
> +
> +         /* Discard BEST_END if it's before the PC of the current BEST.  */
> +         if (best_end <= best->pc)
> +           best_end = 0;
> +       }
> +
>        /* If another line (denoted by ITEM) is in the linetable and its
>           PC is after BEST's PC, but before the current BEST_END, then
>          use ITEM's PC as the new best_end.  */
> 
> 
> -----Original Message-----
> From: gdb-owner@sources.redhat.com
> [mailto:gdb-owner@sources.redhat.com]On Behalf Of Sunil Alankar
> Sent: Sunday, January 05, 2003 3:11 PM
> To: Daniel Jacobowitz
> Cc: gdb@sources.redhat.com
> Subject: RE: GDB 5.2/5.3 breakpoint bug
> 
> 
> Correction to the link for the systemc library sources:
> 
> http://www.systemc.org/download.php/systemc/13/19/systemc-2.0.1.tgz
> 
> Thx
> 
> Sunil
> 
> -----Original Message-----
> From: gdb-owner@sources.redhat.com
> [mailto:gdb-owner@sources.redhat.com]On Behalf Of Sunil Alankar
> Sent: Sunday, January 05, 2003 3:07 PM
> To: Daniel Jacobowitz
> Cc: gdb@sources.redhat.com
> Subject: RE: GDB 5.2/5.3 breakpoint bug
> 
> 
> I guess the e-mail with the attachment of library and include files was not
> delivered. Here it is without attachments.
> The sources for the systemc library/include files are at
> http://www.systemc.org/download.php/systemc/1/4/systemc-1.0.2.tar.gz
> Sunil
> 
> -----Original Message-----
> From: Sunil Alankar [mailto:sunil.alankar@coware.com]
> Sent: Sunday, January 05, 2003 2:48 PM
> To: Daniel Jacobowitz
> Cc: gdb@sources.redhat.com
> Subject: RE: GDB 5.2/5.3 breakpoint bug
> 
> 
> Hi,
>   I have a detailed description of the problem here. Hope this would help. I
> appreciate your help.
> 
> Thank you
> 
> Sunil
> 
> 
> Problem:
> Unable to set class method breakpoints in solaris with gdb 5.3 while using
> systemc
> library in the program.
> 
> Platform:
> SunOS tesla 5.7 Generic_106541-23 sun4u sparc SUNW,Ultra-4
> 
> g++ version:
> Reading specs from
> /eng/devtools/SunOS_5.7/lib/gcc-lib/sparc-sun-solaris2.7/2.95.2/specs
> gcc version 2.95.2 19991024 (release)
> 
> gdb version:
> GNU gdb 5.3
> Copyright 2002 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 "sparc-sun-solaris2.7".
> 
> 
> Test program:
> 
> This error occured while I am debugging a systemC (c++ library for system
> design) program.
> Here is a small example program that demonstrates the problem. ( I have
> attached the
> required library for solaris and include files with the e-mail)
> 
> //-------------------------------------------------------------
> #include <systemc.h>
> 
> SC_MODULE(top)
> {
>  public:
> 
>     sc_in_clk iclk;
> 
>     void func()
>         {
>             printf (".");
>         }
> 
>     SC_CTOR(top)
>         {
>             SC_METHOD(func);
>             sensitive_pos << iclk;
>             dont_initialize();
>         }
> };
> 
> int sc_main (int argc , char *argv[])
> {
>     sc_clock clk("clk", 20);
>     top *top1 = new top("Top1");
>     top1->iclk(clk);
>     sc_start(20000);
>     return 0;
> }
> 
> //-------------------------------------------------------------
> 
> Build the example with:
> % g++ -g -I./include -L./ -lm test1.cpp -lsystemc -o tx
> 
> %/home1/gdb-5.3/gdb/gdb tx
> GNU gdb 5.3
> Copyright 2002 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 "sparc-sun-solaris2.7"...
> (gdb) b top::func
> the class top does not have any method named func
> Hint: try 'top::func<TAB> or 'top::func<ESC-?>
> (Note leading single quote.)
> (gdb)
> 
> 
> In some systemC programs, gdb attempts to set breakpoints at invalid
> addresses.
> 
> This works without a problem in gdb 5.1 with proper breakpoint being set.
> 
> 
> 
> I hope this test case can provide sufficient ground to get at the problem.
> 
> 
> 
> 
> -----Original Message-----
> From: Daniel Jacobowitz [mailto:drow@mvista.com]
> Sent: Friday, January 03, 2003 6:23 PM
> To: Sunil Alankar
> Cc: gdb@sources.redhat.com
> Subject: Re: GDB 5.2/5.3 breakpoint bug
> 
> 
> On Fri, Jan 03, 2003 at 06:15:26PM -0800, Sunil Alankar wrote:
> > Hi,
> >
> >  Attempting to set a class member function breakpoint (say break
> > myClass::funcOne) fails to set a proper break point in solaris 2.7.
> > This happens with GDB 5.2 and 5.3. Bug does not occur in GDB 5.1. Anybody
> > has any idea where to look?. I would appreciate any help.
> 
> What _does_ happen if it isn't a proper breakpoint?  Can you provide a
> transcript?
> 
> What version of what compiler are you using?
> 
> --
> Daniel Jacobowitz
> MontaVista Software                         Debian GNU/Linux Developer
> 
> 

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

RE: GDB 5.2/5.3 breakpoint bug

[Sunil Alankar]

Hi,

While debugging this in function, find_pc_sect_line (CORE_ADDR pc, struct
sec *section, int notcurrent)
I found there were two line items in a line table with the same value of PC.
First one gets picked as the best match. But this had item->line == 0. The
next line item with the same value for item->pc, but a valid item->line ( >
0) does not get picked as the best match.
I put in the following check to correct this. My question is,
Is it valid to have have more than one line item with same value faor PC and
possibly 0 for line in one of them? What causes this?
Would this be an appropriate fix? Or is the problem more deep rooted in
creating the symbol table?

Sunil




--- ../original/gdb-5.3/gdb/symtab.c       Thu Aug 29 20:24:00 2002
+++ gdb-5.3/gdb/symtab.c        Tue Jan  7 14:42:34 2003
@@ -1950,6 +1950,21 @@
            best_end = 0;
        }

+      /* Handle the case where the prev->pc == best->pc due to more than
one line
+        items for a pc, but the best->line == 0. grab a better match if one
exists
+        that has a non zero line number  */
+
+      else if (prev && (!best || ((prev->pc == best->pc) && (best->line ==
0)
+                                 && (prev->line != 0))))
+       {
+         best = prev;
+         best_symtab = s;
+
+         /* Discard BEST_END if it's before the PC of the current BEST.  */
+         if (best_end <= best->pc)
+           best_end = 0;
+       }
+
       /* If another line (denoted by ITEM) is in the linetable and its
          PC is after BEST's PC, but before the current BEST_END, then
         use ITEM's PC as the new best_end.  */


-----Original Message-----
From: gdb-owner@sources.redhat.com
[mailto:gdb-owner@sources.redhat.com]On Behalf Of Sunil Alankar
Sent: Sunday, January 05, 2003 3:11 PM
To: Daniel Jacobowitz
Cc: gdb@sources.redhat.com
Subject: RE: GDB 5.2/5.3 breakpoint bug


Correction to the link for the systemc library sources:

http://www.systemc.org/download.php/systemc/13/19/systemc-2.0.1.tgz

Thx

Sunil

-----Original Message-----
From: gdb-owner@sources.redhat.com
[mailto:gdb-owner@sources.redhat.com]On Behalf Of Sunil Alankar
Sent: Sunday, January 05, 2003 3:07 PM
To: Daniel Jacobowitz
Cc: gdb@sources.redhat.com
Subject: RE: GDB 5.2/5.3 breakpoint bug


I guess the e-mail with the attachment of library and include files was not
delivered. Here it is without attachments.
The sources for the systemc library/include files are at
http://www.systemc.org/download.php/systemc/1/4/systemc-1.0.2.tar.gz
Sunil

-----Original Message-----
From: Sunil Alankar [mailto:sunil.alankar@coware.com]
Sent: Sunday, January 05, 2003 2:48 PM
To: Daniel Jacobowitz
Cc: gdb@sources.redhat.com
Subject: RE: GDB 5.2/5.3 breakpoint bug


Hi,
  I have a detailed description of the problem here. Hope this would help. I
appreciate your help.

Thank you

Sunil


Problem:
Unable to set class method breakpoints in solaris with gdb 5.3 while using
systemc
library in the program.

Platform:
SunOS tesla 5.7 Generic_106541-23 sun4u sparc SUNW,Ultra-4

g++ version:
Reading specs from
/eng/devtools/SunOS_5.7/lib/gcc-lib/sparc-sun-solaris2.7/2.95.2/specs
gcc version 2.95.2 19991024 (release)

gdb version:
GNU gdb 5.3
Copyright 2002 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 "sparc-sun-solaris2.7".


Test program:

This error occured while I am debugging a systemC (c++ library for system
design) program.
Here is a small example program that demonstrates the problem. ( I have
attached the
required library for solaris and include files with the e-mail)

//-------------------------------------------------------------
#include <systemc.h>

SC_MODULE(top)
{
 public:

    sc_in_clk iclk;

    void func()
        {
            printf (".");
        }

    SC_CTOR(top)
        {
            SC_METHOD(func);
            sensitive_pos << iclk;
            dont_initialize();
        }
};

int sc_main (int argc , char *argv[])
{
    sc_clock clk("clk", 20);
    top *top1 = new top("Top1");
    top1->iclk(clk);
    sc_start(20000);
    return 0;
}

//-------------------------------------------------------------

Build the example with:
% g++ -g -I./include -L./ -lm test1.cpp -lsystemc -o tx

%/home1/gdb-5.3/gdb/gdb tx
GNU gdb 5.3
Copyright 2002 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 "sparc-sun-solaris2.7"...
(gdb) b top::func
the class top does not have any method named func
Hint: try 'top::func<TAB> or 'top::func<ESC-?>
(Note leading single quote.)
(gdb)


In some systemC programs, gdb attempts to set breakpoints at invalid
addresses.

This works without a problem in gdb 5.1 with proper breakpoint being set.



I hope this test case can provide sufficient ground to get at the problem.




-----Original Message-----
From: Daniel Jacobowitz [mailto:drow@mvista.com]
Sent: Friday, January 03, 2003 6:23 PM
To: Sunil Alankar
Cc: gdb@sources.redhat.com
Subject: Re: GDB 5.2/5.3 breakpoint bug


On Fri, Jan 03, 2003 at 06:15:26PM -0800, Sunil Alankar wrote:
> Hi,
>
>  Attempting to set a class member function breakpoint (say break
> myClass::funcOne) fails to set a proper break point in solaris 2.7.
> This happens with GDB 5.2 and 5.3. Bug does not occur in GDB 5.1. Anybody
> has any idea where to look?. I would appreciate any help.

What _does_ happen if it isn't a proper breakpoint?  Can you provide a
transcript?

What version of what compiler are you using?

--
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

RE: GDB 5.2/5.3 breakpoint bug

[Sunil Alankar]

Correction to the link for the systemc library sources:

http://www.systemc.org/download.php/systemc/13/19/systemc-2.0.1.tgz

Thx

Sunil

-----Original Message-----
From: gdb-owner@sources.redhat.com
[mailto:gdb-owner@sources.redhat.com]On Behalf Of Sunil Alankar
Sent: Sunday, January 05, 2003 3:07 PM
To: Daniel Jacobowitz
Cc: gdb@sources.redhat.com
Subject: RE: GDB 5.2/5.3 breakpoint bug


I guess the e-mail with the attachment of library and include files was not
delivered. Here it is without attachments.
The sources for the systemc library/include files are at
http://www.systemc.org/download.php/systemc/1/4/systemc-1.0.2.tar.gz
Sunil

-----Original Message-----
From: Sunil Alankar [mailto:sunil.alankar@coware.com]
Sent: Sunday, January 05, 2003 2:48 PM
To: Daniel Jacobowitz
Cc: gdb@sources.redhat.com
Subject: RE: GDB 5.2/5.3 breakpoint bug


Hi,
  I have a detailed description of the problem here. Hope this would help. I
appreciate your help.

Thank you

Sunil


Problem:
Unable to set class method breakpoints in solaris with gdb 5.3 while using
systemc
library in the program.

Platform:
SunOS tesla 5.7 Generic_106541-23 sun4u sparc SUNW,Ultra-4

g++ version:
Reading specs from
/eng/devtools/SunOS_5.7/lib/gcc-lib/sparc-sun-solaris2.7/2.95.2/specs
gcc version 2.95.2 19991024 (release)

gdb version:
GNU gdb 5.3
Copyright 2002 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 "sparc-sun-solaris2.7".


Test program:

This error occured while I am debugging a systemC (c++ library for system
design) program.
Here is a small example program that demonstrates the problem. ( I have
attached the
required library for solaris and include files with the e-mail)

//-------------------------------------------------------------
#include <systemc.h>

SC_MODULE(top)
{
 public:

    sc_in_clk iclk;

    void func()
        {
            printf (".");
        }

    SC_CTOR(top)
        {
            SC_METHOD(func);
            sensitive_pos << iclk;
            dont_initialize();
        }
};

int sc_main (int argc , char *argv[])
{
    sc_clock clk("clk", 20);
    top *top1 = new top("Top1");
    top1->iclk(clk);
    sc_start(20000);
    return 0;
}

//-------------------------------------------------------------

Build the example with:
% g++ -g -I./include -L./ -lm test1.cpp -lsystemc -o tx

%/home1/gdb-5.3/gdb/gdb tx
GNU gdb 5.3
Copyright 2002 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 "sparc-sun-solaris2.7"...
(gdb) b top::func
the class top does not have any method named func
Hint: try 'top::func<TAB> or 'top::func<ESC-?>
(Note leading single quote.)
(gdb)


In some systemC programs, gdb attempts to set breakpoints at invalid
addresses.

This works without a problem in gdb 5.1 with proper breakpoint being set.



I hope this test case can provide sufficient ground to get at the problem.




-----Original Message-----
From: Daniel Jacobowitz [mailto:drow@mvista.com]
Sent: Friday, January 03, 2003 6:23 PM
To: Sunil Alankar
Cc: gdb@sources.redhat.com
Subject: Re: GDB 5.2/5.3 breakpoint bug


On Fri, Jan 03, 2003 at 06:15:26PM -0800, Sunil Alankar wrote:
> Hi,
>
>  Attempting to set a class member function breakpoint (say break
> myClass::funcOne) fails to set a proper break point in solaris 2.7.
> This happens with GDB 5.2 and 5.3. Bug does not occur in GDB 5.1. Anybody
> has any idea where to look?. I would appreciate any help.

What _does_ happen if it isn't a proper breakpoint?  Can you provide a
transcript?

What version of what compiler are you using?

--
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

RE: GDB 5.2/5.3 breakpoint bug

[Sunil Alankar]

I guess the e-mail with the attachment of library and include files was not
delivered. Here it is without attachments.
The sources for the systemc library/include files are at
http://www.systemc.org/download.php/systemc/1/4/systemc-1.0.2.tar.gz
Sunil

-----Original Message-----
From: Sunil Alankar [mailto:sunil.alankar@coware.com]
Sent: Sunday, January 05, 2003 2:48 PM
To: Daniel Jacobowitz
Cc: gdb@sources.redhat.com
Subject: RE: GDB 5.2/5.3 breakpoint bug


Hi,
  I have a detailed description of the problem here. Hope this would help. I
appreciate your help.

Thank you

Sunil


Problem:
Unable to set class method breakpoints in solaris with gdb 5.3 while using
systemc
library in the program.

Platform:
SunOS tesla 5.7 Generic_106541-23 sun4u sparc SUNW,Ultra-4

g++ version:
Reading specs from
/eng/devtools/SunOS_5.7/lib/gcc-lib/sparc-sun-solaris2.7/2.95.2/specs
gcc version 2.95.2 19991024 (release)

gdb version:
GNU gdb 5.3
Copyright 2002 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 "sparc-sun-solaris2.7".


Test program:

This error occured while I am debugging a systemC (c++ library for system
design) program.
Here is a small example program that demonstrates the problem. ( I have
attached the
required library for solaris and include files with the e-mail)

//-------------------------------------------------------------
#include <systemc.h>

SC_MODULE(top)
{
 public:

    sc_in_clk iclk;

    void func()
        {
            printf (".");
        }

    SC_CTOR(top)
        {
            SC_METHOD(func);
            sensitive_pos << iclk;
            dont_initialize();
        }
};

int sc_main (int argc , char *argv[])
{
    sc_clock clk("clk", 20);
    top *top1 = new top("Top1");
    top1->iclk(clk);
    sc_start(20000);
    return 0;
}

//-------------------------------------------------------------

Build the example with:
% g++ -g -I./include -L./ -lm test1.cpp -lsystemc -o tx

%/home1/gdb-5.3/gdb/gdb tx
GNU gdb 5.3
Copyright 2002 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 "sparc-sun-solaris2.7"...
(gdb) b top::func
the class top does not have any method named func
Hint: try 'top::func<TAB> or 'top::func<ESC-?>
(Note leading single quote.)
(gdb)


In some systemC programs, gdb attempts to set breakpoints at invalid
addresses.

This works without a problem in gdb 5.1 with proper breakpoint being set.



I hope this test case can provide sufficient ground to get at the problem.




-----Original Message-----
From: Daniel Jacobowitz [mailto:drow@mvista.com]
Sent: Friday, January 03, 2003 6:23 PM
To: Sunil Alankar
Cc: gdb@sources.redhat.com
Subject: Re: GDB 5.2/5.3 breakpoint bug


On Fri, Jan 03, 2003 at 06:15:26PM -0800, Sunil Alankar wrote:
> Hi,
>
>  Attempting to set a class member function breakpoint (say break
> myClass::funcOne) fails to set a proper break point in solaris 2.7.
> This happens with GDB 5.2 and 5.3. Bug does not occur in GDB 5.1. Anybody
> has any idea where to look?. I would appreciate any help.

What _does_ happen if it isn't a proper breakpoint?  Can you provide a
transcript?

What version of what compiler are you using?

--
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer