From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20547 invoked by alias); 24 Apr 2009 03:28:12 -0000 Received: (qmail 20526 invoked by uid 22791); 24 Apr 2009 03:28:10 -0000 X-SWARE-Spam-Status: No, hits=-1.4 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_33,KAM_STOCKGEN X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 24 Apr 2009 03:28:04 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 6EFB52BAB92; Thu, 23 Apr 2009 23:28:02 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id zqLTJNzarpqA; Thu, 23 Apr 2009 23:28:02 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 37EDB2BAAF1; Thu, 23 Apr 2009 23:28:02 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 2A592F5924; Thu, 23 Apr 2009 20:27:59 -0700 (PDT) Date: Fri, 24 Apr 2009 03:28:00 -0000 From: Joel Brobecker To: Anthony Green Cc: gdb-patches@sourceware.org Subject: Re: PATCH: new gdb port: moxie-elf Message-ID: <20090424032759.GM7552@adacore.com> References: <20090423045725.aaa2c6acbe2fcbd4897bea2c255aade5.61d9530215.wbe@email03.secureserver.net> <20090423182851.GC7552@adacore.com> <49F0FC8C.4010204@moxielogic.com> <20090424000050.GK7552@adacore.com> <49F123A2.7060904@moxielogic.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49F123A2.7060904@moxielogic.com> User-Agent: Mutt/1.5.18 (2008-05-17) Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-04/txt/msg00685.txt.bz2 > Final patch, as committed. Thanks Joel! Great! Just to be certain, please do not forget about sending an RFA for a NEWS entry. Eli, who is our documentation master, would be very disappointed in me if you didn't... Just something you said: > No, I changed this function to use skip_prologue_using_sal()./ Ah ha, I missed that part. And indeed, if I look closer, I see it now: > +static CORE_ADDR > +moxie_skip_prologue (struct gdbarch *gdbarch, CORE_ADDR pc) > +{ > + CORE_ADDR func_addr = 0, func_end = 0; > + char *func_name; > + > + /* See if we can determine the end of the prologue via the symbol table. > + If so, then return either PC, or the PC after the prologue, whichever > + is greater. */ > + if (find_pc_partial_function (pc, &func_name, &func_addr, &func_end)) > + { > + CORE_ADDR post_prologue_pc = skip_prologue_using_sal (func_addr); > + if (post_prologue_pc != 0) > + return max (pc, post_prologue_pc); > + else > + { > + /* Can't determine prologue from the symbol table, need to examine > + instructions. */ > + struct symtab_and_line sal; > + struct symbol *sym; > + struct moxie_frame_cache cache; > + CORE_ADDR plg_end; > + > + memset (&cache, 0, sizeof cache); > + > + plg_end = moxie_analyze_prologue (func_addr, > + func_end, &cache, NULL); > + /* Found a function. */ > + sym = lookup_symbol (func_name, NULL, VAR_DOMAIN, NULL); > + /* Don't use line number debug info for assembly source > + files. */ > + if (sym && SYMBOL_LANGUAGE (sym) != language_asm) > + { > + sal = find_pc_line (func_addr, 0); > + if (sal.end && sal.end < func_end) > + { > + /* Found a line number, use it as end of > + prologue. */ > + return sal.end; > + } > + } > + /* No useable line symbol. Use result of prologue parsing > + method. */ > + return plg_end; > + } > + } > + > + /* No function symbol -- just return the PC. */ > + return (CORE_ADDR) pc; The following is just an observation, not a request to change your code. That's a unusual implementation, more specifically in the second part where skip_prologue_using_sal fails. I am trying to find a case where skip_prologue_using_sal would return zero and yet you'd be able to find a prologue end suing the line table and the only thing I can find is when the function starts with line 2, then goes into line 1. skip_prologue_using_sal would consider lines 2 and 1 to be part of the prologue whereas the second part of your function would only consider the code for line 2. That would probably be wrong. Most implementations I remember that use skip_prologue_using_sal actually look like this: > static CORE_ADDR > rs6000_skip_prologue (struct gdbarch *gdbarch, CORE_ADDR pc) > { > struct rs6000_framedata frame; > CORE_ADDR limit_pc, func_addr; > > /* See if we can determine the end of the prologue via the symbol table. > If so, then return either PC, or the PC after the prologue, whichever > is greater. */ > if (find_pc_partial_function (pc, NULL, &func_addr, NULL)) > { > CORE_ADDR post_prologue_pc = skip_prologue_using_sal (func_addr); > if (post_prologue_pc != 0) > return max (pc, post_prologue_pc); > } > > /* Can't determine prologue from the symbol table, need to examine > instructions. */ > > /* Find an upper limit on the function prologue using the debug > information. If the debug information could not be used to provide > that bound, then use an arbitrary large number as the upper bound. */ > limit_pc = skip_prologue_using_sal (pc); > if (limit_pc == 0) > limit_pc = pc + 100; /* Magic. */ > > pc = skip_prologue (gdbarch, pc, limit_pc, &frame); > return pc; The idea is: Try skip_prologue_using_sal. If that doesn't work, then try to find an upper bound for our prologue, again using sals. If not, then use an arbitrary maximum size for our prologue. Then skip the prologue by doing instruction analysis. In your case, you don't seem to need to have an upper bound in order to do prologue analysis, so you can skiip the part that compute the limit_pc. Just my 2 cents :) -- Joel