Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: "Sunil Alankar" <sunil.alankar@coware.com>
To: "Daniel Jacobowitz" <drow@mvista.com>, <gdb@sources.redhat.com>
Subject: RE: GDB 5.2/5.3 breakpoint bug
Date: Wed, 08 Jan 2003 19:22:00 -0000	[thread overview]
Message-ID: <IMEGIEBLGLIOEGOLAFIEAEOOCEAA.sunil.alankar@coware.com> (raw)
In-Reply-To: <20030108181548.GA27461@nevyn.them.org>



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




  reply	other threads:[~2003-01-08 19:22 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <IMEGIEBLGLIOEGOLAFIEGELNCEAA.sunil.alankar@coware.com>
2003-01-05 23:10 ` Sunil Alankar
2003-01-05 23:14   ` Sunil Alankar
2003-01-07 23:55     ` Sunil Alankar
2003-01-08  0:52       ` Daniel Jacobowitz
2003-01-08 17:39       ` Daniel Jacobowitz
2003-01-08 18:16         ` Daniel Jacobowitz
2003-01-08 19:22           ` Sunil Alankar [this message]
2003-01-08 19:32             ` Daniel Jacobowitz
2003-01-08 19:43               ` Sunil Alankar
2003-01-08 20:42                 ` Sunil Alankar
2003-01-08 20:46                   ` Daniel Jacobowitz
2003-01-08 22:46                     ` Ching Lai
2003-01-09  3:40                       ` Daniel Jacobowitz
2003-01-09  5:18                         ` Ching Lai
2003-01-08 17:30   ` Daniel Jacobowitz
2003-01-08 18:14     ` Sunil Alankar
2003-01-08 18:24       ` Daniel Jacobowitz
2003-01-29  3:56       ` Daniel Jacobowitz
2003-01-02 20:59 how to access show/set data Kris Warkentin
2003-01-04  2:19 ` GDB 5.2/5.3 breakpoint bug Sunil Alankar
2003-01-04  2:23   ` Daniel Jacobowitz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=IMEGIEBLGLIOEGOLAFIEAEOOCEAA.sunil.alankar@coware.com \
    --to=sunil.alankar@coware.com \
    --cc=drow@mvista.com \
    --cc=gdb@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox