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
next prev parent 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