From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27636 invoked by alias); 27 Aug 2014 00:58:49 -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 27621 invoked by uid 89); 27 Aug 2014 00:58:48 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.9 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-ig0-f202.google.com Received: from mail-ig0-f202.google.com (HELO mail-ig0-f202.google.com) (209.85.213.202) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Wed, 27 Aug 2014 00:58:47 +0000 Received: by mail-ig0-f202.google.com with SMTP id r2so831463igi.5 for ; Tue, 26 Aug 2014 17:58:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:mime-version :content-type; bh=PyMXCnMv79+cDaDWam9yLAmUW2pLP6PhbHXgu7Gik0Y=; b=bqK2yzkn1wSmKQq6HHcHYI03olWigmfylwG1zko2dUhgX6nJ9rKlOq5nFVU0abLj+K R7i415mB5f6qRTmZ+m+F9l6u7VwxHq4Y4p7CtdaqpGnNxv0qWaAaIgmSitadVobC7ZXK rQt/XAwC8sRjF3pLa7VBCiOJsTMueYfCiKugRUfNtnrc3iCixVuvSoaNJIjNYJf3PfAY +47VfktFsAoIeELmQM32Dk0RjDZyTfc0UNj4YgxCnXU6x7+H3xjvKfhCQcXcXzff8ZkE UCNTLKOfNFRDg+vp5fAmjCf7YSHxzPNuBq4tP0VeTgCPrZNkdL9ySLiDW+ykZm5TRt6Q rbDA== X-Gm-Message-State: ALoCoQnDGV+U6EKE1oUY+YgEYYAh5+5p+u8xeJoTQ4Isq6234IgkJd2DRPOYLBQyN9KVJLMmh8tJHbfLYhnaf2TZZiNuBRx3enbBzaXRFn/VXOm96c2T2FNRVA84H1UFJiaQ3XdV92KHsh32Irk9+qQTGmpuLiCSgSNNAzwGkovIxJ6j+SEWV38= X-Received: by 10.50.92.104 with SMTP id cl8mr16245790igb.1.1409101124899; Tue, 26 Aug 2014 17:58:44 -0700 (PDT) Received: from corp2gmr1-1.hot.corp.google.com (corp2gmr1-1.hot.corp.google.com [172.24.189.92]) by gmr-mx.google.com with ESMTPS id c77si330327yha.5.2014.08.26.17.58.44 for (version=TLSv1.1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 26 Aug 2014 17:58:44 -0700 (PDT) Received: from ruffy.mtv.corp.google.com (ruffy.mtv.corp.google.com [172.17.128.44]) by corp2gmr1-1.hot.corp.google.com (Postfix) with ESMTPS id 4E0CE31C86C for ; Tue, 26 Aug 2014 17:58:44 -0700 (PDT) From: Doug Evans To: gdb-patches@sourceware.org Subject: aarch64-tdep.c:aarch64_skip_prologue oddity, what's going on??? Date: Wed, 27 Aug 2014 00:58:00 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes X-SW-Source: 2014-08/txt/msg00539.txt.bz2 Hi. I'm trying to fix a few clang-related testsuite failures. amd64,i386,arm have checks for symtab->producer == clang, and the problem is this code doesn't check whether symtab->language == language_asm. I could fix the bug in all three places, but I think some consolidation is in order here (I'd rather fix it in one place instead of three). However, digging deeper I've found something I don't understand. Consider aarch64-tdep.c:aarch64_skip_prologue, though several arches do similar things: [basically, grep for all *-tdep.c files that have two calls to skip_prologue_using_sal] static CORE_ADDR aarch64_skip_prologue (struct gdbarch *gdbarch, CORE_ADDR pc) { unsigned long inst; CORE_ADDR skip_pc; CORE_ADDR func_addr, limit_pc; struct symtab_and_line sal; /* 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); } /* 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 (gdbarch, pc); if (limit_pc == 0) limit_pc = pc + 128; /* Magic. */ /* Try disassembling prologue. */ return aarch64_analyze_prologue (gdbarch, pc, limit_pc, NULL); } I've got several questions here, but some of them may be moot depending on the answers to others, so I'm going to begin slowly. I guess my first question is: Under what circumstances does the above call to find_pc_partial_function return a value for FUNC_ADDR that is not equal to PC? I realize that in the general case, if I pass, e.g., "main+1" for PC then find_pc_partial_function will return "main" for FUNC_ADDR. But when will gdb call gdbarch_skip_prologue with a pc value that is not the start of a function? I realize skip_prologue_sal has this: /* Skip "first line" of function (which is actually its prologue). */ pc += gdbarch_deprecated_function_start_offset (gdbarch); if (gdbarch_skip_entrypoint_p (gdbarch)) pc = gdbarch_skip_entrypoint (gdbarch, pc); if (skip) pc = gdbarch_skip_prologue (gdbarch, pc); gdbarch_deprecated_function_start_offset is only set by vax-tdep.c. gdbarch_skip_entrypoint is only set by ppc-linux-tdep.c. So for these two arches gdbarch_skip_prologue can be called with a pc value greater than the function start address, but how about every other arch? I guess I'm missing something, I'm curious what it is. My second question concerns the above two calls to skip_prologue_using_sal in aarch64-tdep.c:aarch64_skip_prologue. The first thing skip_prologue_using_sal does is call find_pc_partial_function (which is kinda disappointing because we just called it), and if that call fails I think skip_prologue_using_sal will end up returning zero. [btw, shouldn't skip_prologue_using_sal check the return code of find_pc_partial_function?] So, second question: Can we remove both the above call to find_pc_partial_function, and the second call to skip_prologue_using_sal? Or, under what circumstances will the second call to skip_prologue_using_sal return a non-zero value? I've got some experiments to try to shed some light on this, but if anyone has any state they can share, that'd be great. Thanks.