This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
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.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer