From mboxrd@z Thu Jan 1 00:00:00 1970 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: Fri, 10 Dec 1999 16:49:00 -0000 Message-id: <199912110049.QAA11719@andros.cygnus.com> References: <382093BB.3FA78CBD@netwinder.org> X-SW-Source: 1999-q4/msg00365.html Date: Wed, 03 Nov 1999 14:57:47 -0500 From: Scott Bambrough I've made two targets in the configure scripts for ARM: linux and embedded. Basically I have: in gdb/config/arm: embed.mh, embed.mt, nm-embed.h, tm-embed.h, xm-embed.h linux.mh, linux.mt, nm-linux.h, tm-linux.h, xm-linux.h tm-arm.h 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. Most files are very short. The bulk of the definitions are in tm-arm.h. tm-linux.h and tm-embed.h both include this and add/override anything necessary. in gdb: arm-tdep.c, armlinux-nat.c, arm-xdep.o Again, the bulk of the code is in arm-tdep.c. armlinux-nat.c contains stuff specific to linux. I'm not sure what to make of the code in arm-xdep.c. The Linux target makes no use of it, but the embedded target does. Much of it seems geared towards an Acorn machines. I have left it alone. You should have a look at it. 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. If something doesn't seem right, or you don't like what I have done, please say so. Nothing is written in stone. I took the liberty of converting all the code to ANSI (except arm-xdep.c) and started converting all the macros in tm-arm.h to functions in preparation for being multi-arch friendly. I'm certain I have missed a few though. I intend to revisit the code. 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. I don't have suitable environments to test: build=host=sparc-sun-solaris2.5 I'll be testing this, for crosses. 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. Note: There is code in arm-tdep.c for the new call dummy scheme. It was written by Cygnus, and I think Cygnus should enable it and verify its correctness. OK. Breakpoints: I believe I have resolved Andrew Cagney's objections regarding the breakpoint code. The global BREAKPOINT macros are gone, and have been replaced by arm_breakpoint_from_pc(), and macros used to define the various types of breakpoints. I have added commments as he suggested indicating why things are as they are. The following problem with breakpoints still needs to be resolved however: 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. This could be solved by having breakpoint_from_pc() read the instruction at the PC, and merge the condition bits into the breakpoint. Then the breakpoint will only be executed under the same conditions as the original instruction. 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... Stan >From ac131313@cygnus.com Fri Dec 10 20:20:00 1999 From: Andrew Cagney To: Quality Quorum Cc: GDB Patches Subject: Re: another bug in remote.c Date: Fri, 10 Dec 1999 20:20:00 -0000 Message-id: <3851D0A6.26306004@cygnus.com> References: X-SW-Source: 1999-q4/msg00366.html Content-length: 750 [cc set to gdb-patches] Quality Quorum wrote: > > Hi, > > I got another bug. This time I do not know how to fix it. > It is possible to get into following sequence of of events: > > gdb: $m4000ab70,c8#22 -- asks for 200 bytes of memory > stub: $<400 chars>#XX -- stub responds correctly, packet > length 404 bytes > gdb: Remote packet too long -- gdb unhappy > > I suspect that PBUFSIZ should not be used to determine > max_buf_size in remote_read_bytes(). It seems like there are > more places where similar problem may occur. Just a quick check. How up-to-date are your sources. Does the ChangeLog contain entries from me where I drop a buffer from 400 to 399? Andrew >From qqi@world.std.com Fri Dec 10 20:44:00 1999 From: Quality Quorum To: Andrew Cagney Cc: GDB Patches Subject: Re: another bug in remote.c Date: Fri, 10 Dec 1999 20:44:00 -0000 Message-id: References: <3851D0A6.26306004@cygnus.com> X-SW-Source: 1999-q4/msg00367.html Content-length: 942 On Sat, 11 Dec 1999, Andrew Cagney wrote: > [cc set to gdb-patches] > > Quality Quorum wrote: > > > > Hi, > > > > I got another bug. This time I do not know how to fix it. > > It is possible to get into following sequence of of events: > > > > gdb: $m4000ab70,c8#22 -- asks for 200 bytes of memory > > stub: $<400 chars>#XX -- stub responds correctly, packet > > length 404 bytes > > gdb: Remote packet too long -- gdb unhappy > > > > I suspect that PBUFSIZ should not be used to determine > > max_buf_size in remote_read_bytes(). It seems like there are > > more places where similar problem may occur. > > Just a quick check. How up-to-date are your sources. Does the ChangeLog > contain entries from me where I drop a buffer from 400 to 399? No, it does not. I suspect dropping PBUFSIZ would not help in the case anyway. > > Andrew > Thanks, Aleksey