Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Doug Evans <dje@google.com>
To: Yao Qi <yao@codesourcery.com>
Cc: <gdb-patches@sourceware.org>
Subject: Re: [PATCH 2/6] DW attribute macro MACRO_AT_func and MACRO_AT_range
Date: Tue, 04 Nov 2014 22:59:00 -0000	[thread overview]
Message-ID: <21593.23093.954591.53113@ruffy2.mtv.corp.google.com> (raw)
In-Reply-To: <1414195968-3333-3-git-send-email-yao@codesourcery.com>

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  <yao@codesourcery.com>
 > 
 > 	* 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?


  parent reply	other threads:[~2014-11-04 22:59 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-25  0:17 [PATCH 0/6] Use correct function address in dwarf assembler Yao Qi
2014-10-25  0:18 ` [PATCH 4/6] Use Dwarf::assemble in implptr-optimized-out.exp Yao Qi
2014-11-04 22:53   ` Doug Evans
2014-10-25  0:18 ` [PATCH 2/6] DW attribute macro MACRO_AT_func and MACRO_AT_range Yao Qi
2014-11-04 22:50   ` Doug Evans
2014-11-05  1:54     ` Yao Qi
2014-11-07 16:54       ` Doug Evans
2014-11-10  2:04         ` Yao Qi
2014-11-10 19:44           ` Doug Evans
2014-11-11  2:05             ` Yao Qi
2014-11-12  7:01               ` Doug Evans
2014-11-14  1:00                 ` Yao Qi
2014-11-04 22:59   ` Doug Evans [this message]
2014-10-25  0:18 ` [PATCH 1/6] New proc _handle_attribute Yao Qi
2014-11-04 22:48   ` Doug Evans
2014-10-25  0:18 ` [PATCH 3/6] Get start and end address of main in dwz.exp Yao Qi
2014-11-04 22:51   ` Doug Evans
2014-10-25  0:18 ` [PATCH 6/6] Fix dw2-ifort-parameter.exp fail with clang Yao Qi
2014-11-04 22:54   ` Doug Evans
2014-10-25  0:18 ` [PATCH 5/6] Fix implptr-optimized-out.exp fail Yao Qi
2014-11-04 22:53   ` Doug Evans
2014-11-04 23:01 ` [PATCH 0/6] Use correct function address in dwarf assembler Doug Evans

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=21593.23093.954591.53113@ruffy2.mtv.corp.google.com \
    --to=dje@google.com \
    --cc=gdb-patches@sourceware.org \
    --cc=yao@codesourcery.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox