From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19937 invoked by alias); 26 Jan 2006 23:47:28 -0000 Received: (qmail 19923 invoked from network); 26 Jan 2006 23:47:24 -0000 Received: from unknown (202.80.33.51) by sourceware.org with QMTP; 26 Jan 2006 23:47:24 -0000 Received: (qmail 8991 invoked from network); 26 Jan 2006 23:47:20 -0000 X-Anti-Virus: Message scanned for viruses by TVL Received: from unknown (HELO [192.168.2.14]) ([202.80.36.20]) (envelope-sender ) by mail.vanuatu.com.vu (qmail-ldap-1.03) with SMTP for ; 26 Jan 2006 23:47:20 -0000 Message-ID: <43D95F88.70802@sakuraindustries.com> Date: Thu, 26 Jan 2006 23:47:00 -0000 From: Accounts User-Agent: Mozilla Thunderbird 1.0.6-7.2.20060mdk (X11/20050322) MIME-Version: 1.0 To: Daniel Jacobowitz CC: Mark Kettenis , ngustavson@emacinc.com, gdb-patches@sourceware.org Subject: Re: frame theory, was pointer madness References: <200601231438.26040.ngustavson@emacinc.com> <200601261354.12256.ngustavson@emacinc.com> <200601262121.k0QLLGfw017308@elgar.sibelius.xs4all.nl> <200601261552.46222.ngustavson@emacinc.com> <200601262240.k0QMe7SC026344@elgar.sibelius.xs4all.nl> <20060126224429.GA20076@nevyn.them.org> In-Reply-To: <20060126224429.GA20076@nevyn.them.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-01/txt/msg00443.txt.bz2 Daniel Jacobowitz wrote: >He's connecting to basically a standard gdbserver, poised at >the first instruction of the program. Memory has garbage >and/or is invalid - no MMU so reading from garbage memory >is a bit more serious than is typical for GDB. > >The best thing here would be, if the stub can find out from >the kernel what constitutes "valid" RAM, to refuse reads to >it. Then ignore the ugliness when you type backtrace and >don't have a stack yet - it's not real surprising that doesn't >work! > > > This sort of issue can be a BIG problem for embedded targets (it has been for every embedded target ive used ARM and PowerPC/MPC8XX). Ive talked about it before in previous posts. Its worse when you use a hardware interface for your "Stub" like a JTAG pod, BDM, or the like, because then there is no Kernel to tell you if you have valid memory or not (The kernel hasnt run yet). There are also times on embedded devices when the nominal stack pointer register isnt a stack pointer register at all (for example immediately after reset of a cpu, before the boot code has had a chance to set up the system), and dereferences of it are "Bad News", can cause corruption of the target under the certain circumstances and generally make embedded systems development hell (at that level). On Thu, Jan 26, 2006 at 11:40:07PM +0100, Mark Kettenis wrote: >To me, it looks like you're connecting to a buggy stub. > > I dont think its fair to say these things are "Buggy Stubs" just because GDB lately has the view there is ALWAYS a stack, which just isnt correct. Also, the stubs probably pre-date GDB's new frame unwinding code, so really its GDB that has changed in an incompatible way with previously working stubs. Having to work around this in a stub is a real pain. The issue is the stub cant determine whats a memory access command the user wants to do, and what is an automatic GDB generated memory access, as it does a frame unwind. So there is no nice way to make a stub say "No Stack memory yet" even if it knew it. Ive often thought GDB should have a "No ABI" option that completely prevents any stack/frame unwinding operations from working, so these sorts of problems go away when there is no ABI, and then when the user knows the target is properly set up, the user can re-enable the targets ABI, which allows these stack memory accesses to occur. Ive even looked at how it could be done, but it seems a very complicated thing, and i could never quite work out a way to achieve it. (Due to a complete lack of understanding of the frame code). Also, for the record, my experience is GDB does this stuff even if you dont execute a backtrace, it is done automatically when the stub connects. Its like it is unwinding the frame to set up a cache or something. Steven Johnson