From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24377 invoked by alias); 4 Nov 2014 22:59:07 -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 24367 invoked by uid 89); 4 Nov 2014 22:59:06 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.2 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; Tue, 04 Nov 2014 22:59:05 +0000 Received: by mail-ig0-f202.google.com with SMTP id r10so78160igi.5 for ; Tue, 04 Nov 2014 14:59:03 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:mime-version:content-type :content-transfer-encoding:message-id:date:to:cc:subject:in-reply-to :references; bh=8esjQ9g87Seobt2sbtGVtQPQjQS/BBJY3OXO54M4gOo=; b=RTSSFCdK8GyiwxnHIHqS4i6V1soRJ7DmOyEyfu+fQCcxttsvlPutKFPE/zLpr99G0d t+k6ZC3CtRRr1MhCFpwr+6KL4wSqH1Lk6EMxK1Vy9znltdQ8CLl0yZjzo7IyWPK/d842 UxBJwriYlTw+VcXBZ4JLlcbYSHysFzv2yZsnq4nESLKwQ/efJTfiACwG+twRGeGqHmZr tHajuSiPW6JLvBQkn2KtYJhtBtLTWdufKAzN22HoDuN4PcBIiIoMQ2PBsbIX8Ii6a1Bg t8etccbm1ezH2PuXuBf70BeuQ9FRg1Yr6Db0GLyFKIqBz7QsVzOrOBNyL8enBrZiuLcr gghQ== X-Gm-Message-State: ALoCoQm8daKQBfcEDIo+ZE00PmE1cShyHjkfKJMHCaheWGvkLL7gbpuTA3bA85K5Jksxstjmk2yPpjXdADiS9nQhz0FXP3EM7kLPUXkJKpuJBHd4lhPUrttL7NfgYks8iOPuk1NFm00zX1ZNzQpEsf8z1zFMujATzRyX9984idbE2zoZTPVkxPU= X-Received: by 10.43.7.68 with SMTP id on4mr923273icb.13.1415141943014; Tue, 04 Nov 2014 14:59:03 -0800 (PST) Received: from corpmail-nozzle1-2.hot.corp.google.com ([100.108.1.103]) by gmr-mx.google.com with ESMTPS id s23si38663yhf.0.2014.11.04.14.59.02 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Nov 2014 14:59:02 -0800 (PST) Received: from ruffy2.mtv.corp.google.com ([172.17.128.107]) by corpmail-nozzle1-2.hot.corp.google.com with ESMTP id jRNbBZ45.1; Tue, 04 Nov 2014 14:59:02 -0800 From: Doug Evans MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21593.23093.954591.53113@ruffy2.mtv.corp.google.com> Date: Tue, 04 Nov 2014 22:59:00 -0000 To: Yao Qi Cc: Subject: Re: [PATCH 2/6] DW attribute macro MACRO_AT_func and MACRO_AT_range In-Reply-To: <1414195968-3333-3-git-send-email-yao@codesourcery.com> References: <1414195968-3333-1-git-send-email-yao@codesourcery.com> <1414195968-3333-3-git-send-email-yao@codesourcery.com> X-IsSubscribed: yes X-SW-Source: 2014-11/txt/msg00087.txt.bz2 Yao Qi writes: > This patch addes DW macro attributes MACRO_AT_func and MACRO_AT_range > in dwarf assembler, which emits "DW_AT_low_pc func_start addr" and > "DW_AT_high_pc func_end addr". func_start and func_end are computed > automatically by proc function_range. > > These two attributes are pseudo attribute or macro attribute, which > means they are not standard dwarf attribute in dwarf spec. Then can > be substituted or expanded to standard attributes or macro attributes. > See details in the comments to them. Dwarf assembler is extended to > handle them. > > Now the attributes name/low_pc/high_pc can be replaced with > MACRO_AT_func like this: > > subprogram { > {name main} > {low_pc main_start addr} > {high_pc main_end addr} > } > > becomes: > > subprogram { > {MACRO_AT_func { main ${srcdir}/${subdir}/${srcfile} }} > } > > users don't have to worry about the start and end of function main, and > they only need to add a label main_label in main. > > gdb/testsuite: > > 2014-10-24 Yao Qi > > * lib/dwarf.exp (function_range): New procedure. > (Dwarf::_handle_macro_attribute): New procedure. > (Dwarf): Handle MACRO_AT_func and MACRO_AT_range. > --- > gdb/testsuite/lib/dwarf.exp | 128 +++++++++++++++++++++++++++++++++++++++++--- > 1 file changed, 122 insertions(+), 6 deletions(-) > > diff --git a/gdb/testsuite/lib/dwarf.exp b/gdb/testsuite/lib/dwarf.exp > index 4986f83..401e791 100644 > --- a/gdb/testsuite/lib/dwarf.exp > +++ b/gdb/testsuite/lib/dwarf.exp > @@ -86,6 +86,81 @@ proc build_executable_from_fission_assembler { testname executable sources optio > return 0 > } > > +# Return a list of expressions about function FUNC's address and length. > +# The first expression is the address of function FUNC, and the second > +# one is FUNC's length. SRC is the source file having function FUNC. > +# An internal label ${func}_label must be defined inside FUNC: > +# > +# int main (void) > +# { > +# asm ("main_label: .globl main_label"); > +# return 0; > +# } > +# > +# This label is needed to compute the start address of function FUNC. > +# If the compiler is gcc, we can do the following to get function start > +# and end address too: > +# > +# asm ("func_start: .globl func_start"); > +# static void func (void) {} > +# asm ("func_end: .globl func_end"); > +# > +# however, this isn't portable, because other compilers, such as clang, > +# may not guarantee the order of global asms and function. The code > +# becomes: > +# > +# asm ("func_start: .globl func_start"); > +# asm ("func_end: .globl func_end"); > +# static void func (void) {} > +# > + > +proc function_range { func src } { > + global decimal gdb_prompt > + > + set exe [standard_temp_file func_addr[pid].x] > + > + gdb_compile $src $exe executable {debug} > + > + gdb_exit > + gdb_start > + gdb_load "$exe" > + > + # Compute the label offset, and we can get the function start address > + # by "${func}_label - $func_label_offset". > + set func_label_offset "" > + set test "p ${func}_label - ${func}" > + gdb_test_multiple $test $test { > + -re ".* = ($decimal)\r\n$gdb_prompt $" { > + set func_label_offset $expect_out(1,string) > + } > + } > + > + # Compute the function length. > + global hex > + set func_length "" > + set test "disassemble $func" > + gdb_test_multiple $test $test { > + -re ".*$hex <\\+($decimal)>:\[^\r\n\]+\r\nEnd of assembler dump\.\r\n$gdb_prompt $" { > + set func_length $expect_out(1,string) > + } > + } > + > + # Compute the size of the last instruction. > + set test "x/2i $func+$func_length" > + gdb_test_multiple $test $test { > + -re ".*($hex) <$func\\+$func_length>:\[^\r\n\]+\r\n\[ \]+($hex).*\.\r\n$gdb_prompt $" { > + set start $expect_out(1,string) > + set end $expect_out(2,string) > + > + set func_length [expr $func_length + $end - $start] > + } > + } > + > + file delete $exe > + > + return [list "${func}_label - $func_label_offset" $func_length] > +} > + In the immortal words of Shrek, "Hold the phone." ... "file delete $exe" is a local operation. While in general we don't delete test artifacts, I'm left wondering if something about this won't work with remote host testing. Is that true? Or can "file delete $exe" just be deleted?