From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott Bambrough To: Philip Blundell Cc: gdb-patches@sourceware.cygnus.com Subject: Re: Merge of ARM Linux port with existing ARM code... Date: Wed, 15 Dec 1999 11:54:00 -0000 Message-id: <3857F0F7.D92A607B@netwinder.org> References: <199912110049.QAA11719@andros.cygnus.com> <3857DC13.438069C4@netwinder.org> X-SW-Source: 1999-q4/msg00392.html Philip Blundell wrote: > > For the benefit of those of us who didn't see your original message (I guess > it wasn't posted to the list), could you explain what the problem in question > actually is? We have actually discussed the problem before Phil. It is the problem with predicated instructions and breakpoints. The messages actually did go to the list. I have included the archive urls below. These are the messages in question: http://sourceware.cygnus.com/ml/gdb-patches/1999-q4/msg00163.html http://sourceware.cygnus.com/ml/gdb-patches/1999-q4/msg00365.html Cheers, Scott -- Scott Bambrough - Software Engineer REBEL.COM http://www.rebel.com NetWinder http://www.netwinder.org >From shebs@cygnus.com Wed Dec 15 11:54:00 1999 From: Stan Shebs To: Philip.Blundell@pobox.com Cc: gdb-patches@sourceware.cygnus.com Subject: Re: Merge of ARM Linux port with existing ARM code... Date: Wed, 15 Dec 1999 11:54:00 -0000 Message-id: <199912151954.LAA07033@andros.cygnus.com> References: X-SW-Source: 1999-q4/msg00393.html Content-length: 1024 Date: Wed, 15 Dec 1999 18:30:43 +0000 From: Philip Blundell >> The usual approach to solving this kind of problem is to copy the >> instructions somewhere else and execute them there. It's really hairy >> to make work, usually implementors try to avoid the situation. But in >> the ARM case, you would break the instruction into a multi-instruction >> sequence consisting of simpler instructions, then put the breakpoint >> at the simpler instruction that best corresponds to the source location. >> There would be some guessing as to which instruction was meant... > >This sounds like a horrible hack. I'll think about it. For the benefit of those of us who didn't see your original message (I guess it wasn't posted to the list), could you explain what the problem in question actually is? The original was posted to gdb-patches by Scott B on 3 November; URL is http://sourceware.cygnus.com/ml/gdb-patches/1999-q4/msg00163.html . Stan >From shebs@cygnus.com Wed Dec 15 14:06:00 1999 From: Stan Shebs To: scottb@netwinder.org 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 14:06:00 -0000 Message-id: <199912152124.NAA07105@andros.cygnus.com> References: <3857DC13.438069C4@netwinder.org> X-SW-Source: 1999-q4/msg00394.html Content-length: 3309 Date: Wed, 15 Dec 1999 13:21:07 -0500 From: Scott Bambrough > That's a great start in the right direction. We can always come back > and polish the code later on. I'll get the basic stuff in, then you > can check it over in the next snap and tell me what I missed. It doesn't seem to be in this weeks snapshot, will it be in next weeks? Yes. It took longer than I expected to separate the cosmetic changes from the functional changes; in general we don't like to put in mixes of both, because it becomes very difficult to track down the causes of problems later on. ARM is getting a lot of attention right now, so I need to be careful not to crumble anything... > Shared library support: > Both targets make use of IN_SOLIB_CALL_TRAMPOLINE. This needs to be > resolved for ARM-Thumb compatibility. At the moment this is not > implemented on Linux, and Thumb is not an issue on Linux (at this very > moment at least). I have to get this support going, and I will resolve > it then. > > Embedded ARM won't care about this one. Are you sure? If the embedded Linux project takes off, this may become an issue. By "embedded ARM" I meant the arm-{elf,coff} configs, which are mainly for bare boards with little or no OS. Embedded ARM Linux is an interesting issue though; should the GDB for it be the generic arm-elf GDB or a new and different config? At this point I don't know; for EL/IX experimentation I think they're using a standard cross GDB, but that will need to change to accommodate all four levels of the EL/IX API. ( http://sourceware.cygnus.com/elix for EL/IX info) > I suspect this issue has always been around, but nobody has noticed > because you don't get the move+condition in unoptimized code. Optimized > code debugging will be squirrelly like it always is. There is no point in debugging unoptimized code. The generated code for -O0/-O2 is so different, it rarely suffers from the same problems. This has been my experience. 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. 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 problems here are very deep and common to all debugging. If you review the research literature, it's clear that while there's been some progress, it's still too limited in scope to be really useful for GDB. Still, it would be cool for someone to extend the state of the art and demo it in GDB first - any volunteers? Stan