From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30196 invoked by alias); 11 Mar 2014 11:58:53 -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 30180 invoked by uid 89); 11 Mar 2014 11:58:52 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 X-HELO: mail-we0-f171.google.com Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com) (74.125.82.171) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Tue, 11 Mar 2014 11:58:51 +0000 Received: by mail-we0-f171.google.com with SMTP id t61so9878246wes.2 for ; Tue, 11 Mar 2014 04:58:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=UyQd3vReUj51MLN3e2/vRwXR2InJ0lCzwYIeoernIdc=; b=FyFYkkENF3ksR0iLOZ591wnwU9VFYwXNo2hxeTcE5VuTe/yBDpN7d+qbFa7SiBsjNe 3qq/k+onQMGBdwlAM8rDE3aBHoGiSuK/yuV+ZSGM1MIPWw/++AF6kazjCpRwk0Byp7pN 1dR8VlixerGofvbH2CTdHZy1SOk+9j6dAbjlX/TINIQX8i8+kvz646DkYlKlo8Zb5S/D x+dg1gianCmCLZF4dZjutFVbGYTGcyaQzRJAH4hal2Fsm171YGX9lOfk9hspbX/YHDB2 Wi9lYefZcNPdQXmdTpcYmYvgCx40F9UEIkePDQuAmeL4PqY0rK2r+W3TOSJCKwH0YEP1 JV+A== X-Gm-Message-State: ALoCoQmcMNnmBfohISOAjFuXhDScgXiQB/54na7kIieT18BTWhrCheWPN9pqzDqhUB4Rm6pQLy8Q X-Received: by 10.181.13.82 with SMTP id ew18mr2720977wid.22.1394539127843; Tue, 11 Mar 2014 04:58:47 -0700 (PDT) Received: from [172.21.9.11] (visitornet-pat.nomadic.bristol.edu. [193.60.198.36]) by mx.google.com with ESMTPSA id 12sm60923841wjm.10.2014.03.11.04.58.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 11 Mar 2014 04:58:47 -0700 (PDT) Message-ID: <531EFA75.10008@embecosm.com> Date: Tue, 11 Mar 2014 11:58:00 -0000 From: Pierre Langlois User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Joel Brobecker , gdb-patches@sourceware.org Subject: Re: [PATCH][PR breakpoints/16606] AVR8 breakpoint out of range, decrement pc after break References: <531A2316.5090507@embecosm.com> <20140310110809.GC4882@adacore.com> In-Reply-To: <20140310110809.GC4882@adacore.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2014-03/txt/msg00261.txt.bz2 Hello Joel, Thank you for the input. On 10/03/14 11:08, Joel Brobecker wrote: > Hello Pierre, > >> For example: >> >> (gdb) break *0x10e >> would result in a breakpoint at the address 0x80010e, out of range. >> diff --git a/gdb/avr-tdep.c b/gdb/avr-tdep.c >> index 6e58f04..a4a4a6d 100644 >> --- a/gdb/avr-tdep.c >> +++ b/gdb/avr-tdep.c >> @@ -333,7 +333,10 @@ avr_integer_to_address (struct gdbarch *gdbarch, >> { >> ULONGEST addr = unpack_long (type, buf); >> >> - return avr_make_saddr (addr); >> + if (TYPE_CODE_SPACE (type)) >> + return avr_make_iaddr (addr); >> + else >> + return avr_make_saddr (addr); >> } >> >> static CORE_ADDR >> @@ -1436,6 +1439,7 @@ avr_gdbarch_init (struct gdbarch_info info, struct gdbarch_list *arches) >> set_gdbarch_inner_than (gdbarch, core_addr_lessthan); >> >> set_gdbarch_breakpoint_from_pc (gdbarch, avr_breakpoint_from_pc); >> + set_gdbarch_decr_pc_after_break (gdbarch, 2); > This part seems fine, but it would be good if you could submit it > separately, with an explanation of the problem you are seeing > (a copy of the gdb debugging session is often useful). OK, I'll split this patch in two. >> frame_unwind_append_unwinder (gdbarch, &avr_frame_unwind); >> frame_base_set_default (gdbarch, &avr_frame_base); >> diff --git a/gdb/linespec.c b/gdb/linespec.c >> index 610809d..8355114 100644 >> --- a/gdb/linespec.c >> +++ b/gdb/linespec.c >> @@ -2588,6 +2588,7 @@ initialize_defaults (struct symtab **default_symtab, int *default_line) >> static CORE_ADDR >> linespec_expression_to_pc (const char **exp_ptr) >> { >> + struct value *val; >> if (current_program_space->executing_startup) >> /* The error message doesn't really matter, because this case >> should only hit during breakpoint reset. */ >> @@ -2595,7 +2596,14 @@ linespec_expression_to_pc (const char **exp_ptr) >> "program space is in startup")); >> >> (*exp_ptr)++; >> - return value_as_address (parse_to_comma_and_eval (exp_ptr)); >> + val = parse_to_comma_and_eval (exp_ptr); >> + /* The value given by parse_to_comma_and_eval is an address but does not have >> + any information about the address space in which it resides. Harvard >> + architectures need to know this when converting a value to an address with >> + gdbarch_integer_to_address. It is safe to assume linespecs give an address >> + in code space. */ >> + TYPE_INSTANCE_FLAGS (value_type (val)) |= TYPE_INSTANCE_FLAG_CODE_SPACE; >> + return value_as_address (val); > I don't think it's correct to be doing that, as the type you are > modifying is not specific to the value being returned. The change > you are making is therefore affecting other values, and cause > incorrect output for values of that type. > > The way we have been dealing with this sort of issue is basically > to add a cast to a function pointer to the expression. If you really > want to support this feature, you'll probably want to store the > information in the value rather than the type. But I am a little > less familiar with struct value, so others might a better suggestion. I just realized that support for multiple address spaces was added but never documented. So the way to solve the issue is to add the @code qualifier as such: (gdb) break * (@code void *) 0x10e And it will set the TYPE_CODE_SPACE instance flag to the type when calling integer_to_address. However, shouldn't @code be the default for breakpoints? I'm investigating how to do this, any pointers?