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?
next prev 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