From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19510 invoked by alias); 19 Nov 2001 21:30:40 -0000 Mailing-List: contact gdb-patches-help@sourceware.cygnus.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 19426 invoked from network); 19 Nov 2001 21:30:33 -0000 Received: from unknown (HELO localhost.cygnus.com) (216.138.202.10) by sourceware.cygnus.com with SMTP; 19 Nov 2001 21:30:33 -0000 Received: from cygnus.com (localhost [127.0.0.1]) by localhost.cygnus.com (Postfix) with ESMTP id 2CA0F3D7E; Mon, 19 Nov 2001 16:30:32 -0500 (EST) Message-ID: <3BF979F7.4090207@cygnus.com> Date: Wed, 07 Nov 2001 17:56:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:0.9.3) Gecko/20011020 X-Accept-Language: en-us MIME-Version: 1.0 To: Daniel Jacobowitz Cc: gdb-patches@sources.redhat.com Subject: Re: [rfa] Mips heuristic_proc_desc vs. the stack pointer. References: <20011116162423.A30736@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2001-11/txt/msg00129.txt.bz2 > As HJ noticed, we try to read the stack pointer in heuristic_proc_desc. I'm > not sure why this normally works and fails with linuxthread support, but I'm > convinced it's sometimes wrong. If we are called from after_prologue(), the > stack pointer has nothing to do with the function we're trying to generate a > desc for. We shouldn't try to read it in this case. The uses of it in > *_heuristic_proc_desc are harmless. Regarding the threads, are you saying things still sometimes break with your patch applied? I suspect there was the usual GDB internal thread coherency problem where different parts of GDB were debugging different threads. > Is this OK, Andrew? Yes, but can you please adjust the following before committing: > * mips-tdep.c (find_proc_desc): Add read_sp argument. Update all > callers. Given the updates were not identical / mechanical, could you please list each making it clear that after_prologue() was the exception. Can you please add a comment to after_prologue() explaining why the SP shouldn't be fetched in that case. Can the argument be called read_sp_p (say?) rather than read_sp. There is a global function read_sp that is hiding behind that variable. > (heuristic_proc_desc): Likewise. Do not read SP if read_sp == 0. enjoy, Andrew