This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 2/6] DW attribute macro MACRO_AT_func and MACRO_AT_range
- From: Doug Evans <dje at google dot com>
- To: Yao Qi <yao at codesourcery dot com>
- Cc: <gdb-patches at sourceware dot org>
- Date: Tue, 4 Nov 2014 14:59:01 -0800
- Subject: Re: [PATCH 2/6] DW attribute macro MACRO_AT_func and MACRO_AT_range
- Authentication-results: sourceware.org; auth=none
- References: <1414195968-3333-1-git-send-email-yao at codesourcery dot com> <1414195968-3333-3-git-send-email-yao at codesourcery dot 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?