Re: Merge of ARM Linux port with existing ARM code...

[Scott Bambrough <scottb@netwinder.org>]

Stan Shebs wrote:
> 
> You're right about the size of the descrepancy between -O0 and -O2,
> but I think it's going a bit far to say "there is no point in
> debugging unoptimized code".  Almost all of my own debugging work is
> done on unoptimized code.

I agree with you in fact.  But in many cases when I had problems they
only occurred in optimized code.   The problem goes away or never
occurred in unoptimized code.  Which was really the point I wanted to
make.

> GDB's official position on optimized code is to allow the debugger to
> work with it, but not to promise very much functionality.  -O2 in GCC
> includes ever-more-aggressive optimizations, and it's going to be hard
> or impossible for GDB to reconstruct the original code in all cases.
> Conditional moves are a primo example - you have a single instruction
> that is an amalgam of several source lines, and you want GDB to
> present the illusion that it can do several statement-level steps,
> when the actual hardware will do only one instruction-level step.  For
> GDB, an instruction-level step is an atomic operation.  How do you
> divide up an atom?  (Use a cyclotron, of course :-) )

The problem is much more general on the ARM.  Every instruction is
conditional, or can be anyway.  If you put a breakpoint on such an
instruction the breakpoint is executed unconditionally currently even if
the execution is conditional.  If you ignore high level languages
altogether and assume only assembler source.

cmp 	r0, #0
suble	r1, r2, r3
addgt	r1, r2, r3

If the above construct is part of a loop, placing a breakpoint on the
subtraction operation causes it to break once per loop.  What if you are
only interested in the case when the instruction is actually executed? 
Say it is only executed once in a million iterations of the loop.  You
can hit a lot of breakpoints before you get to the point the instruction
is actually executed.  Why not let the CPU decide if a breakpoint is
required by using the condition predicate for the instruction in the
breakpoint instruction?

Scott

-- 
Scott Bambrough - Software Engineer
REBEL.COM    http://www.rebel.com
NetWinder    http://www.netwinder.org
From jimb@cygnus.com Wed Dec 15 23:52:00 1999
From: Jim Blandy <jimb@cygnus.com>
To: law@cygnus.com
Cc: Srikanth Adayapalam <srikanth@cup.hp.com>, gdb-patches@sourceware.cygnus.com
Subject: Re: (patch) hpjyg09: bcache optimizations
Date: Wed, 15 Dec 1999 23:52:00 -0000
Message-id: <npogbr5nmr.fsf@zwingli.cygnus.com>
References: <970.945248225@upchuck>
X-SW-Source: 1999-q4/msg00396.html
Content-length: 1101

>   > > 	While it is true that it is not tied to the microprocessor,
>   > > (and the placement of the macro is not ideal perhaps,) it is tied 
>   > > somewhat to the HP-UX platform in that :
>   > 
>   > Ahh.  That, I didn't know.  So it would be correct to put the flag in
>   > a file associated with a particular toolchain.
> Not in this case.  While HP's tools arrange (via pxdb) to avoid duplicates,
> other HP toolchains do not.
> 
> Short term none of the GNU toolchains on the PA remove duplicates.  That will
> likely change for the PA64 toolchain (dwarf2 + elf), but it is unlikely to 
> ever change for the PA32 toolchain (stabs + som).
> 
> In general, if we find ourselves tuning towards one particular
> toolchain, then we are probably going down the wrong road.

As it turned out, I rewrote the bcache so it works better.  I haven't
heard back from HP on this, but I suspect its overhead is now low
enough that they wouldn't have noticed it to begin with.  So, as
symtab maintainer, hpjyg09 is now dead, until I hear an explanation of
why the changes to the bcache were insufficient.
From law@cygnus.com Thu Dec 16 00:03:00 1999
From: Jeffrey A Law <law@cygnus.com>
To: Jim Blandy <jimb@cygnus.com>
Cc: gdb-patches@sourceware.cygnus.com, dnovillo@cygnus.com
Subject: Re: getting patches organized 
Date: Thu, 16 Dec 1999 00:03:00 -0000
Message-id: <4586.945331241@upchuck>
References: <199911172343.SAA28254@zwingli.cygnus.com>
X-SW-Source: 1999-q4/msg00397.html
Content-length: 1872

  In message < 199911172343.SAA28254@zwingli.cygnus.com >you write:
  > 
  > As folks have probably figured out, I'm beginning to have a hard time
  > keeping track of the patches that I'm responsible for reviewing, which
  > patches I have reviewed, whether the submitter has gotten back to me
  > about my comments, etc.
  > 
  > This situation is worsened when some urgent issue appears on some
  > Cygnus project I'm responsible for, and I have to focus on that for a
  > few weeks.  When I come back, it's difficult for me to recover all the
  > state I'd built up before I was drawn away.
  > 
  > It's been suggested that we could use a bug-tracking system like GNATS
  > or Bugzilla as a patch-tracking system.  We'd change the status values
  > to some set like "Awaiting-Review", "Awaiting-Revision", "Approved",
  > "Applied", "Rejected", "Withdrawn", or whatever.
  > 
  > The only system I'm really familiar with is GNATS.  GNATS can
  > automatically stash E-mail conversation related to a patch in the
  > patch record ("PR"), which is exactly what we want.  It's got web
  > interfaces, a decent query ability, and so on.  So I think it would
  > work great.
  > 
  > What would the folks on this list who are actually submitting patches
  > want from such a system?  Certainly all the data would be public.
  > What else should we worry about?
Note that we're looking into setting something similar up for GCC;  we
were going to initially try to deploy something for use internally within 
Cygnus's GCC group first, tune it, then try to deploy it for all GCC patches.

There isn't anything directly designed for patch tracking, but like y'all we
came to the conclusion that packages with do a good job at bug tracking
ought to be adaptable.

Diego -- can you forward that initial summary you sent to the Cygnus GCC team
to the Jim & the GDB folks.

jeff