From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29568 invoked by alias); 7 Mar 2014 19:50:56 -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 29556 invoked by uid 89); 7 Mar 2014 19:50:55 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 X-HELO: mail-we0-f178.google.com Received: from mail-we0-f178.google.com (HELO mail-we0-f178.google.com) (74.125.82.178) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Fri, 07 Mar 2014 19:50:53 +0000 Received: by mail-we0-f178.google.com with SMTP id u56so5608710wes.9 for ; Fri, 07 Mar 2014 11:50:50 -0800 (PST) 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:content-type; bh=7LHri4Iuo5/M/wVMqEdsRgy/2OuGNzACFoDyqxp92fw=; b=TKyVkX6CMaz+UgUAoCrK8WuHuPCgpuquXB4Y+LRIU5TIn/U1BEDGOIu1cGzCmaMAFb I8hZ2S5PGaL3Ppx6RUnTiyct8Prh9IDPF3HFeN8CHS9j+7NsvsZqP1vl91HubwLsUzlU Z3+5s86AxKtdIV0L8hKgmzml1zt5Gfhzmvw6I0t/3U6Y+f2LPBbegQCX4RT23NuuyBJG d3FBZiqF75n3Sd+ax81JXRvSZw8d6MNZ5v7b5JIWtCfgjCVNUBzUl4Y+eYoDz7Nybr6R ZOBnY1OmU+puWSry90ATlZqveZ13zzhwRcmbzmIWnJPmO4uFfdl7ADWAlQB8gxZWsZJw vx1w== X-Gm-Message-State: ALoCoQmjqfZnrrpfQOad6JvDPDl0f9f49nTgzPu9uhqJ30LO9M1yqC4LombVj1LgRDwubJT8CWkL X-Received: by 10.194.90.233 with SMTP id bz9mr21485033wjb.65.1394221850244; Fri, 07 Mar 2014 11:50:50 -0800 (PST) Received: from [192.168.0.134] (cust64-dsl91-135-5.idnet.net. [91.135.5.64]) by mx.google.com with ESMTPSA id dd3sm13905783wjb.9.2014.03.07.11.50.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 07 Mar 2014 11:50:48 -0800 (PST) Message-ID: <531A2316.5090507@embecosm.com> Date: Fri, 07 Mar 2014 19:50: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: gdb-patches@sourceware.org Subject: [PATCH][PR breakpoints/16606] AVR8 breakpoint out of range, decrement pc after break Content-Type: multipart/mixed; boundary="------------090507090209090206000509" X-IsSubscribed: yes X-SW-Source: 2014-03/txt/msg00207.txt.bz2 This is a multi-part message in MIME format. --------------090507090209090206000509 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-length: 1227 Firstly, this patch fixes issuing breakpoints using an address expression on AVR. For example: (gdb) break *0x10e would result in a breakpoint at the address 0x80010e, out of range. AVR is an harvard architecture and we use the top bits of the internal addresses to determine whether this is a code address or a data address. In this case, 0x800000 was applied to this address because it was considered to be a data address. A more detailed explanation of this behaviour can be found on bugzilla: https://sourceware.org/bugzilla/show_bug.cgi?id=16606#c1 When returning a struct value from the evaluation of *0x10e, nothing in this value indicates that it resides in code space. In this case the expression is a linespec, referring to source code, so we can safely assume the address is in code space. We can set the TYPE_CODE_SPACE instance flag on the type of the value. When the value is converted to an address, gdbarch_integer_to_address can apply the correct mask depending on TYPE_CODE_SPACE. This fix unveiled another issue, the program counter was not decremented after hitting the breakpoint instruction. This patch fixes this by adding gdbarch_decr_pc_after_break to AVR's gdbarch. Best, Pierre --------------090507090209090206000509 Content-Type: text/x-patch; name="pr-breakpoint-16606.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="pr-breakpoint-16606.patch" Content-length: 1967 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); 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); } --------------090507090209090206000509--