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



-----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




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