From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6873 invoked by alias); 4 Aug 2003 16:35:04 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 6849 invoked from network); 4 Aug 2003 16:35:03 -0000 Received: from unknown (HELO concert.shout.net) (204.253.184.25) by sources.redhat.com with SMTP; 4 Aug 2003 16:35:03 -0000 Received: from duracef.shout.net (duracef.shout.net [204.253.184.12]) by concert.shout.net (8.12.9/8.12.9) with ESMTP id h74GYxbA013596; Mon, 4 Aug 2003 11:34:59 -0500 Received: from duracef.shout.net (localhost [127.0.0.1]) by duracef.shout.net (8.12.9/8.12.9) with ESMTP id h74GYxHK003321; Mon, 4 Aug 2003 11:34:59 -0500 Received: (from mec@localhost) by duracef.shout.net (8.12.9/8.12.9/Submit) id h74GYxRk003320; Mon, 4 Aug 2003 12:34:59 -0400 Date: Mon, 04 Aug 2003 16:35:00 -0000 From: Michael Elizabeth Chastain Message-Id: <200308041634.h74GYxRk003320@duracef.shout.net> To: ezannoni@redhat.com Subject: Re: backtrace through 'sleep', (1255 and 1253) Cc: drow@mvista.com, gdb@sources.redhat.com X-SW-Source: 2003-08/txt/msg00044.txt.bz2 eza> yes. How did the prologue analyzer changed between 5.3 and now? The prologue analyzer got refactored, but it looks like basically the same code. There's nothing that understands 'xor %ecx, %ecx' in the 5.3 code. In 5.3, i386_frame_chain looks for a frameless function. It has some simple tests and it doesn't call the prologue analyzer. If it can't decide whether the function is frameless or not, then i386_frame_chain assumes that is framed. That works for 'sleep'. In gdb HEAD, i386_frame_chain directly calls the prologue analyzer. If the prologue analyzer can't handle it, then i386_frame_chain assumes that is frameless (the code that I quoted). >From a user point of view, the workaround for today would be: use the debugging version of glibc, or use the static version of glibc. I really don't want to ship gdb 6.0 like that but if we don't fix gdb then I'll write something like that for PROBLEMS. I looked at the 'abstract interpretation' code in s390-tdep.c. I think this is the right solution for gdb HEAD. For gdb 6.0, I think that shoving 'xor %reg, %reg' into the existing prologue reader is probably good enough to get us through the release. I will make a patch for this later this week if no one beats me to it. The sinking feeling I have is that this problem will affect a lot of architectures, not just i386. Michael C