From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 45576 invoked by alias); 24 Jun 2018 19:28:41 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 45567 invoked by uid 89); 24 Jun 2018 19:28:40 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=realized, evaluating, closer, 002 X-HELO: mail-wm0-f53.google.com Received: from mail-wm0-f53.google.com (HELO mail-wm0-f53.google.com) (74.125.82.53) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 24 Jun 2018 19:28:39 +0000 Received: by mail-wm0-f53.google.com with SMTP id u18-v6so3182427wmc.1 for ; Sun, 24 Jun 2018 12:28:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:mime-version :content-transfer-encoding; bh=eTb/XvTTTvQxRfe17c/XXF0QwY8RhuWHT27EWUP3lGA=; b=jiK73PabV2ODUX+MZMBGZgHeZOEO7CyMKtK0eXCJ+MKMSHyQIH7WmPrAnxeOVPGX6W UMveXulBrpeN21P5tWhDnVHJOyOKiU9sIVjkG2jRvDdF4MXq4rwz5jSLuYVYUWpoHUJC p9U0FFLlNdOoHhPL055FnTaAwnYWdPCoVi8xrXD/En00LNJlJBCPhB+97DZT3iGfUVU9 D6H5g63oXldCBdnV5N8zkUOHix8N3ShqnSktPUm4nOJudjcVxwrlh9Mp/5G28T3l1wAh GvrZ99ValnihMpHN7F7pkFCTZiQcUOlUFfb/BTTi6XsGfhX9oqMzt1ETVj0S1QGme65h Nj3Q== X-Gm-Message-State: APt69E3ZtvIL//3oqNizNUXfkLW2AmUwdxYOgCNTBwPJPS+b1h2XbA6Z OKtH0e2doS3fdgEZZ5yF4aiGaw== X-Google-Smtp-Source: ADUXVKLxP/KgHe0T5i5mp4ZM5xzgMEtEsXxVEEJ/x8LqqyE7vCyqQ3giPa15De6nQRXMD7WGPLnqxg== X-Received: by 2002:a1c:4602:: with SMTP id t2-v6mr3683004wma.21.1529868516959; Sun, 24 Jun 2018 12:28:36 -0700 (PDT) Received: from [192.168.1.11] ([105.228.65.154]) by smtp.gmail.com with ESMTPSA id u204-v6sm1750858wmd.7.2018.06.24.12.28.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 24 Jun 2018 12:28:36 -0700 (PDT) Message-ID: <1529868512.24104.26.camel@gmail.com> Subject: AVR - invalid address used when evaluating a variable From: Christo To: gdb@sourceware.org Cc: christo.crause@gmail.com Date: Sun, 24 Jun 2018 19:28:00 -0000 Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2018-06/txt/msg00008.txt.bz2 I am testing the debugging of AVR microcontrollers over debugWIRE with gdb. When evaluating the value of a variable I noticed an incorrect value. On closer inspection I realized that gdb (8.1 compiled for AVR support) was reading flash memory, not SRAM.  When I evaluate the pointer to the variable, gdb correctly reports the SRAM address. When reading the memory pointed to by this pointer the correct value is returned.  This leads me to postulate that there is a mistake/omission when gdb evaluates/prints a variable, resolve its address and then reads it from flash rather than SRAM. Below a short excerpt of debugging a simple program with a variable "i" which the compiler located at address 0 in SRAM (which should be mapped to 0x800060, right after the io registers). The program was compiled with Freepascal and debugged using a debugWIRE server.  I've called "set debug remote 1" so that the rsp requests can be seen: (gdb) print i Sending packet: $m60,1#30...Ack Packet received: 20 $7 = 32 ' ' (gdb) print &i $8 = (Byte *) 0x800060 Sending packet: $m800060,8#ff...Ack Packet received: 020003B8F6777DD2 "\002" (gdb) print *&i Sending packet: $m800060,1#f8...Ack Packet received: 02 $9 = 2 '\002' Can anyone confirm this behaviour is indeed wrong/unexpected?