From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-1.mimecast.com (us-smtp-delivery-1.mimecast.com [207.211.31.120]) by sourceware.org (Postfix) with ESMTP id 0CC86388A833 for ; Sun, 24 May 2020 16:36:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 0CC86388A833 Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-47-JkDmWOF4O6a21WxUyM3reA-1; Sun, 24 May 2020 12:36:39 -0400 X-MC-Unique: JkDmWOF4O6a21WxUyM3reA-1 Received: by mail-wr1-f72.google.com with SMTP id 3so50351wrs.10 for ; Sun, 24 May 2020 09:36:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=TfJlImG176wYfvRasgy2iJ+beGikCswJFTGPny0J5CI=; b=cncidlJAWJjVZM1WLA6CLB/kWZscukB1rKGKKtSd6P6VX91YLHRYEhS7DQJgCbciEf GMSycnsrjSc/amErKaWZnav1bAJmh/nlcOYtcPgsxBSdAKNY9LtTMp/yNRvVHGuqgx81 S4XBJnFeWgcRjGjQrOJqud2/JJ/QuweSRpOQSkB9gF0HesxkGNqetUYTcFHnahTJTHu3 /dIUekBrG/i08LwHzTNsLF88zYbLaiqMiLHupD/ktj2MvJJ64UcvDe7UKA4wTEymxqcx 4Wot4Vd0Ny8GQ+0nzXmmwoMdzXnURFROV3G78EsvOUe23yYKfXJk7z17hatx8XAft1OQ YHQA== X-Gm-Message-State: AOAM533O6cgx1cRJj5WoQIpH7CsegEl9fUNmWTcRzrGaKgYM3t4seZZ7 wFwH/i21NOD/IACgL0BxGMXeIny829MbdDYNhqa043VpJrNIxOJlBg3V0UMkUEz4/cTkv+Gl6K3 oG/yZUQs1GCBJf6wI/XcQag== X-Received: by 2002:adf:ec03:: with SMTP id x3mr8676234wrn.297.1590338198760; Sun, 24 May 2020 09:36:38 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwIfx1UlMMxuDqFRVa4ue49VaSa3Hh0dGiRXQBSm5XkZyw5g9jFi5pIjdE3q1LGuDcKfNbTmg== X-Received: by 2002:adf:ec03:: with SMTP id x3mr8676222wrn.297.1590338198569; Sun, 24 May 2020 09:36:38 -0700 (PDT) Received: from ?IPv6:2001:8a0:f909:7b00:2327:23ca:3e56:ef5f? ([2001:8a0:f909:7b00:2327:23ca:3e56:ef5f]) by smtp.gmail.com with ESMTPSA id s8sm12929055wrg.50.2020.05.24.09.36.37 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 24 May 2020 09:36:37 -0700 (PDT) Subject: Re: [PATCH 2/2] gdb: make avr_integer_to_address generate code or data address based on type To: Simon Marchi , gdb-patches@sourceware.org References: <20200524142040.209234-1-simon.marchi@polymtl.ca> <20200524142040.209234-2-simon.marchi@polymtl.ca> Cc: Cristiano De Alti From: Pedro Alves Message-ID: <25d51e8d-f59a-82e0-ed65-eb173f7b69a4@redhat.com> Date: Sun, 24 May 2020 17:36:36 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <20200524142040.209234-2-simon.marchi@polymtl.ca> Content-Language: en-US X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.9 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 May 2020 16:36:45 -0000 On 5/24/20 3:20 PM, Simon Marchi via Gdb-patches wrote: > From: Cristiano De Alti > > I (Simon Marchi) am re-sending this patch written by Cristiano De Alti: > > https://sourceware.org/legacy-ml/gdb-patches/2016-03/msg00318.html > > The commit message is new but the code has not changed. > > The AVR architecture is a Harvard one, meaning it has different memory > spaces for code and data. In GDB, this is dealt with by having the data > (SRAM) addresses start at 0x00800000. When interpreting an integer as > an address (converting to a CORE_ADDR), we currently always generate a > data address. This doesn't work for some cases described below, where > the integer is meant to represent a code address. > > This patch changes avr_integer_to_address so that it generates the > correct type of address (code or data) based on the passed type. > > Using the simavr.exp board, I didn't see any regressions when running > the gdb.base/*.exp tests. A few tests go from fail to pass, but none > from pass to fail. There are a few new fails and unresolved, but it's > just because some tests manage to make more progress before failing in a > different way. > > In practice, it fixes disassembling by address, as described in the PR: > > - (gdb) disassemble 0x12a,0x12b > - Dump of assembler code from 0x12a to 0x12b: > - 0x0000012a : push r28 > - End of assembler dump. > > + (gdb) disassemble 0x12a,0x12b > + Dump of assembler code from 0x80012a to 0x80012b: > + 0x0080012a: nop > + End of assembler dump. > > And also, setting a breakpoint by address: > > - (gdb) p &main > - $1 = (int (*)(void)) 0x12a
> - (gdb) b *0x12a > - Breakpoint 1 at 0x80012a > > + (gdb) p &main > + $1 = (int (*)(void)) 0x12a
> + (gdb) b *0x12a > + Breakpoint 1 at 0x12a: file test-avr.c, line 3. > + Note: automatically using hardware breakpoints for read-only addresses. > > gdb/ChangeLog: > > PR gdb/13519 > * avr-tdep.c (avr_integer_to_address): Return data or code > address accordingly to the second 'type' argument of the > function. Thank you for writing the commit log. LGTM. Pedro Alves