This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: GDB 5.2/5.3 breakpoint bug


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
>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]