From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14526 invoked by alias); 3 Sep 2014 17:19:33 -0000 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 Received: (qmail 14505 invoked by uid 89); 3 Sep 2014 17:19:31 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-vc0-f175.google.com Received: from mail-vc0-f175.google.com (HELO mail-vc0-f175.google.com) (209.85.220.175) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Wed, 03 Sep 2014 17:19:30 +0000 Received: by mail-vc0-f175.google.com with SMTP id lf12so9079529vcb.20 for ; Wed, 03 Sep 2014 10:19:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=pTSfeS1zkY2D3XfSw65w/zR8jHPhRU7o7++D3ZmOR8M=; b=JF6/ZRwf7apL8Owjj/hRB9SW6oZxoi3W0VUw2CO+qt47CPKh98tLuf2y5R+bE9RdfX ojmygsWPfZDt5Hw9Mw5bESw8wErPgS9+Qaz9gWq/+GmV9k3ALVACpci0fIYaTPiaM212 BnApIO84woDSb4JCiPm56ag/FHUEODxFHsSAlYSMQhYCywVvGzXWnTjNPP6WvivzkpsK fPuB+pPImcVOzbxwvTIOYMApxhczVroWdG4RARfiKdUgYkS9kmNPLHW2IJu392tYQjT+ ZZE3pGz5udt1HYP639jWTfqu+ID8NPOOp/adleOouB3atl267ySu6mdzBpefDgtEP0Gc 1kVA== X-Gm-Message-State: ALoCoQn3/ewDUbfnW/XUzCwzXMdu37GQCOyhy5+HBjzqzCL/PtBxeR2+GYWBmcvmQkJMab8yYv94 MIME-Version: 1.0 X-Received: by 10.220.168.210 with SMTP id v18mr36342729vcy.3.1409764768147; Wed, 03 Sep 2014 10:19:28 -0700 (PDT) Received: by 10.52.136.203 with HTTP; Wed, 3 Sep 2014 10:19:28 -0700 (PDT) In-Reply-To: References: Date: Wed, 03 Sep 2014 17:19:00 -0000 Message-ID: Subject: Re: [PATCH] Remove some obfuscation from ${arch}_skip_prologue functions From: Doug Evans To: gdb-patches Cc: "Maciej W. Rozycki" , green@moxielogic.com, Yao Qi Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2014-09/txt/msg00093.txt.bz2 On Tue, Sep 2, 2014 at 4:53 PM, Doug Evans wrote: > Hi. > > This patch is a follow up to an observation made here: > https://sourceware.org/ml/gdb-patches/2014-08/msg00539.html > > [...] > > At the very least, I'd like to document Why Things Are The Way They Are > if there is indeed a reason for it. > > [...] btw, there is still one aspect here that I don't understand the WHY of: aarch64-tdep.c and others do this (grep for <<<<): /* 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 (gdbarch, func_addr); if (post_prologue_pc != 0) return max (pc, post_prologue_pc); //<<<< } Why? Why max (pc, post_prologue_pc) ? Is it because ${arch}_skip_prologue can be called with a pc value greater than the start address of the function? If so, when? Are people just being conservative because it's not clear what values of pc may be passed to ${arch}_skip_prologue? [If so we've got unnecessarily complex code due to unclear APIs ... bleah.] N.B. There are only two arches that I could find where (I think) the pc passed to ${arch}_skip_prologue could be different than the function's entry point: 1) vax, which sets deprecated_function_start_offset 2) ppc-linux (elf v2), which sets skip_entrypoint If I'm missing something ... great ... let's get it documented. [And if it is documented, let's make it easier to find. :-) The prologue stuff I can find from the Internals Wiki doesn't discuss this, and I wasn't about to read the entire wiki looking for it.]