From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott Bambrough To: Stan Shebs Cc: jingham@cygnus.com, gdb-patches@sourceware.cygnus.com Subject: Re: Merge of ARM Linux port with existing ARM code... Date: Wed, 15 Dec 1999 15:43:00 -0000 Message-id: <385826AF.F4B5A31E@netwinder.org> References: <199912152124.NAA07105@andros.cygnus.com> X-SW-Source: 1999-q4/msg00395.html 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 To: law@cygnus.com Cc: Srikanth Adayapalam , gdb-patches@sourceware.cygnus.com Subject: Re: (patch) hpjyg09: bcache optimizations Date: Wed, 15 Dec 1999 23:52:00 -0000 Message-id: 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 To: Jim Blandy 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