Re: [aeb] Re: GNU toolchain and AEB

[Jens-Christian Lache <lache at tu-harburg dot de>]

Hi Fernando! Thanks for the hint about the infinite recursion 
in symtab.c from gdb. Working fine now. Lately we talked about
the download speed of gdb to the aeb. I couldnīt find
a logic or network analyser explicitly made for serial debugging.
That means, the only choice would be to use a normal analyser.
I would have to program it to make it recognize the serial protocol.
This is too much work for me, I havenīt used an analyser yet.

I want tp play little with the timings of gdb. Maybe it is not waiting
long enough when having issued the transfere rate switch.
At which files should I look?

Best regards,
Jens-Christian 

Am Mit, 17 Jan 2001 schrieben Sie:
> 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:  fnasser@redhat.com
> 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 <jingham@apple.com>
> To: gdb-patches@sources.redhat.com
> 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  <jingham@inghji.apple.com>
> 
>          * symtab.c (lookup_symbol_aux): Call lookup_symbol_aux to 
> lookup a
>          mangled symbol rather than recursing into lookup_symbol, since 
> this
>          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, 
> symtab);
>              }
>            /* 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, 
> symtab);
>              }
>            /* There are no debug symbols for this file, or we are looking
-- 


Jens-Christian Lache
Technische Universitaet Hamburg-Harburg
www.tu-harburg.de/~sejl1601
Mail:
lache@tu-harburg.de
lache@ngi.de
Tel.:
+0491759610756