This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 2/2] Fix implptr-optimized-out.exp fail in thumb mode
- From: Doug Evans <dje at google dot com>
- To: Yao Qi <yao at codesourcery dot com>
- Cc: gdb-patches <gdb-patches at sourceware dot org>
- Date: Wed, 8 Oct 2014 11:31:59 -0400
- Subject: Re: [PATCH 2/2] Fix implptr-optimized-out.exp fail in thumb mode
- Authentication-results: sourceware.org; auth=none
- References: <1411951921-16168-1-git-send-email-yao at codesourcery dot com> <1411951921-16168-3-git-send-email-yao at codesourcery dot com>
On Sun, Sep 28, 2014 at 8:52 PM, Yao Qi <yao@codesourcery.com> wrote:
> Hi,
> I see the fail in gdb.dwarf2/implptr-optimized-out.exp in thumb mode
>
> (gdb) p p->f^M
> No symbol "p" in current context.^M
> (gdb) FAIL: gdb.dwarf2/implptr-optimized-out.exp: p p->f
>
> In thumb mode, the lsb of references to 'main' in the assembly
> (produced by dwarf assember) is set, so the generated debug
> information is incorrect.
>
> in this patch, we add a label main_label inside function main. Linker
> doesn't set its lsb in thumb mode, and we can get function main's
> address by 'main_label - $main_label_offset'.
>
> gdb/testsuite:
>
> 2014-09-29 Yao Qi <yao@codesourcery.com>
>
> * gdb.dwarf2/implptr-optimized-out.exp: Compile main.c to object.
> Calculate the offset of main_label to main. Compile the generated
> asm file and link the executable.
> (Dwarf::assemble): Get address of main by
> main_label - $main_label_offset.
> ---
> gdb/testsuite/gdb.dwarf2/implptr-optimized-out.exp | 39 ++++++++++++++++++++--
> 1 file changed, 36 insertions(+), 3 deletions(-)
>
> diff --git a/gdb/testsuite/gdb.dwarf2/implptr-optimized-out.exp b/gdb/testsuite/gdb.dwarf2/implptr-optimized-out.exp
> index 649f52d..534bed0 100644
> --- a/gdb/testsuite/gdb.dwarf2/implptr-optimized-out.exp
> +++ b/gdb/testsuite/gdb.dwarf2/implptr-optimized-out.exp
> @@ -22,9 +22,35 @@ if {![dwarf2_support]} {
> standard_testfile main.c .S
> set executable ${testfile}
>
> +if {[gdb_compile ${srcdir}/${subdir}/${srcfile} ${binfile}1.o \
> + object {}] != ""} {
> + return -1
> +}
> +# Start GDB and load object file, compute the offset from main to
> +# main_label which are needed in the Dwarf Assembler below.
> +clean_restart ${binfile}1.o
> +
> +set main_label_offset ""
> +set test "p main_label - main"
> +gdb_test_multiple $test $test {
> + -re ".* = ($decimal)\r\n$gdb_prompt $" {
> + set main_label_offset $expect_out(1,string)
> + }
> +}
> +
> +if { $main_label_offset == "" } {
> + # Bail out here, because we can't do the following tests if
> + # $main_label_offset is unknown.
> + return -1
> +}
> +
> +gdb_exit
> +
> # Create the DWARF.
> set asm_file [standard_output_file $srcfile2]
> Dwarf::assemble $asm_file {
> + global main_label_offset
> +
> cu { version 3 } {
> compile_unit {
> {producer "GNU C 4.4.3"}
> @@ -52,8 +78,8 @@ Dwarf::assemble $asm_file {
>
> subprogram {
> {name main}
> - {low_pc main addr}
> - {high_pc main+0x100 addr}
> + {low_pc "main_label - $main_label_offset" addr}
> + {high_pc "main_label - $main_label_offset + 0x100" addr}
> {type :$int_label}
> {external 1 flag}
> } {
> @@ -80,10 +106,17 @@ Dwarf::assemble $asm_file {
> }
> }
>
> -if [prepare_for_testing ${testfile}.exp $executable "${asm_file} ${srcfile}" {}] {
> +if {[gdb_compile $asm_file ${binfile}0.o object {}] != ""} {
> return -1
> }
>
> +if {[gdb_compile [list ${binfile}0.o ${binfile}1.o] \
> + "${binfile}" executable {}] != ""} {
> + return -1
> +}
> +
> +clean_restart ${testfile}
> +
> # DW_OP_GNU_implicit_pointer implementation requires a valid frame.
> if ![runto_main] {
> return -1
Hi.
One question that comes to mind is: If this solution is going to
proliferate it would be good to convince ourselves there's no better
solution. I'm ok with this as a one-off here and there, but I'd like
to understand how many more of these will there be. Plus I can
imagine of course the number growing over time.
Can we, for example, enhance the dwarf assembler and provide a hook
for the thumb target to use to fix this there?
But *if* we do decide there's no better solution, there's a lot of
boilerplate here.
Can we tuck it away in a utility?