This is the mail archive of the 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]

Re: [aeb] Re: GNU toolchain and AEB

Jens-Christian Lache wrote:
> Hi Fernando! Could you reproduce the problem?
> I really could need a "working" debugger! I have seen the bug described below
> not only in the toolstips, but also while trying to watch objects.

Yes, Jim Ingham has contributed a fix for that.  I didn't realize you were not
in the insight mailing list (I forwarded it to the list).  I added Jim's message
with the patch to the end of this message.

> I donīt use optimization, but sometimes it feels like debugging optimized code.
> (It does this funny jumping in the code, even if there are no jump commands).

That is correct and unavoidable.  As the compiler interlaces the instructions that
were originated by different source code lines, debugging optimized code will
show the current line going back and forth.  This is the reality of the code 
produced.  The debugger is telling the truth.

To avoid this you can debug non-optimized code (if you are testing basic
functionality this should no be a big problem.

Another option woul be to use the MIXED mode in the Insight Source Window so you
get a better idea of where the instruction came from (if you are confortable 
with assembler).

> The following looks also strange to me:
>         74      void TaskList::insert(Task * pTask)
> -       75      {
> -       76              Task * ppPrev = this->pTop;
>         77
>         78              //
>         79              // Handle  the case of an empty list.
>         80              //
> -       81              if (ppPrev == NULL)
>         82              {
>         83                      ppPrev == pTask;
>         84                      return;
>         85              }
> This is how it looks in gdb. No instruction at "ppPrev == pTask; " and
> "return;  ".

This is a very trivial method and it probably got optimized in some smart way.
Use the MIXED mode to see what are the assembler instructions that were 
associated with the source lines.

> I am doing this embedded programming for the first time. I didnīt thought
> that it is that hard.
> Sorry to be that impatient! Itīs just urgend for me! :-)
> Best regards,
> Jens-Christian
> Am Don, 11 Jan 2001 schrieben Sie:
> >
> > Hi everybody!
> > This is a bug report about:
> >
> > Today I encounter a problem with the gdb. I had the tooltips for variables
> > turned on. When moving the mousepointer over a field of a class, gdb startet to
> > allocote ruff amounts of mem. Only the limit of 128MB of swap could stop
> > it, it crashed and my X crashed too. I could mail you the project
> > and explain you how to reproduce this error.
> >
> > This is how to reproduce it:
> >
> > 1.) install & say "make" in the adeos dir
> > 2.) download & start it to a AT91EB01 or AT91EB40
> > It will stop in "main" at "os.start();"
> > 3.) set a breakpoint in sched.cpp, function "Sched::start(void)",
> > third line "schedule();"
> > 4.) continue
> > 5.) move mousepointer over "state" from the line above
> > "state = Started;" Having
> > tooltips turned on, it should crash. Or try to add it to the list of
> > watch exprecions.
> >
> > My arm-elf-gdb is from 20001212.
> >
> > Regards,
> >
> > Jens-Christian
> >

Fernando Nasser
Red Hat - Toronto                       E-Mail:
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

-------- Original Message --------
Date: Fri, 12 Jan 2001 11:35:34 -0800
Mime-Version: 1.0 (Apple Message framework v366)
From: Jim Ingham <>
X-Mailer: Apple Mail (2.366)
Content-Transfer-Encoding: 7bit
Subject: [patch] fix for infinite recursion in lookup_symbol

Hi, all,

The following patch fixes an infinite recursion in the variable lookup 
code for C++ objects that are specified in mangled form.  The old code 
would take the mangled name into lookup_symbol, unmangle it, and then in 
this bit pass the mangled name BACK to lookup_symbol, which would 
unmangle it and come right back here...  Not a good thing.  The bug 
crept in when lookup_symbol was broken up into lookup_symbol and 
lookup_symbol_aux, the correction is clearly what was meant.

2001-01-09  James Ingham  <>

         * symtab.c (lookup_symbol_aux): Call lookup_symbol_aux to 
lookup a
         mangled symbol rather than recursing into lookup_symbol, since 
         will just re-unmangle the name & call lookup_symbol_aux - 
leading to
         an infinite recursion.

Index: symtab.c
RCS file: /cvs/src/src/gdb/symtab.c,v
retrieving revision 1.15
diff -c -w -r1.15 symtab.c
*** symtab.c    2000/09/04 08:29:25     1.15
--- symtab.c    2001/01/12 19:29:21
*** 754,760 ****
               /* This is a mangled variable, look it up by its
                  mangled name.  */
!             return lookup_symbol (SYMBOL_NAME (msymbol), block,
                                     namespace, is_a_field_of_this, 
           /* There are no debug symbols for this file, or we are looking
--- 754,760 ----
               /* This is a mangled variable, look it up by its
                  mangled name.  */
!             return lookup_symbol_aux (SYMBOL_NAME (msymbol), block,
                                     namespace, is_a_field_of_this, 
           /* There are no debug symbols for this file, or we are looking

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