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 10:25:00 -0000 Message-id: <3857DC13.438069C4@netwinder.org> References: <199912110049.QAA11719@andros.cygnus.com> X-SW-Source: 1999-q4/msg00388.html Stan Shebs wrote: > Actually, the embed config doesn't need .mh, nm, or xm files, so I'm > leaving those out. The rest of these files look fine, and I'm basically > putting them in verbatim. That's great. Thanks. > I'm going to be marking arm-xdep.c as obsolete, as I've done with > other files. They'll be around for the next releases, then disappear > sometime after that. Ok. > 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? > 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. > 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. > 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. Scott -- Scott Bambrough - Software Engineer REBEL.COM http://www.rebel.com NetWinder http://www.netwinder.org >From Philip.Blundell@pobox.com Wed Dec 15 10:31:00 1999 From: Philip Blundell To: Scott Bambrough Cc: Stan Shebs , jingham@cygnus.com, gdb-patches@sourceware.cygnus.com Subject: Re: Merge of ARM Linux port with existing ARM code... Date: Wed, 15 Dec 1999 10:31:00 -0000 Message-id: References: <199912110049.QAA11719@andros.cygnus.com> <3857DC13.438069C4@netwinder.org> X-SW-Source: 1999-q4/msg00389.html Content-length: 752 >> 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? Thanks p.