From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-f177.google.com (mail-lj1-f177.google.com [209.85.208.177]) by sourceware.org (Postfix) with ESMTPS id E2BFF3851C22 for ; Mon, 22 Mar 2021 17:38:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org E2BFF3851C22 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=rtems.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=joel.sherrill@gmail.com Received: by mail-lj1-f177.google.com with SMTP id 15so22201145ljj.0 for ; Mon, 22 Mar 2021 10:38:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc; bh=GhNBm7Fb+iKbW+lZSg5U3bjj3CtPcxXVWHSnojZiHPA=; b=AE/W7b+5Qv6g0pHgUoH/ka+EKOoz8ieuD4OKCsLlAPTMbsDTkaztmhvpDEpFcC0sRE 0df0G/ha2NUMvfvD1W7vCGxZcvTJofbvD92ra6iUdPmJWmy36iuQ6qwAEbqPFQLcqVvW I7JcBAyPDohnFVQLQR0uS2rAeHdfmdR2gHNPUAUkqgXytXehk67WLPn3qKrY+L7IAkbW CZ9nA9pWBBICtpxQBrykLlMK9qiNQfRhX2kJ+vDHxVRgweL0KUdw8YT3sGeHjYYGq3Ow SB84PSzUHVF68jAvJQ1Mzp6KEZWBkGht3xP+SmL5a/sMDqD39xBiE4hDGdj9kdjFYhvJ aVMw== X-Gm-Message-State: AOAM531K3VqdVdnutrKMtMCWjpapj+GSWT7oBN6BQbNUKHEUj3M808AW rSvEQqZ4RVxS8LKLhz/g42BoW6O9+6s= X-Google-Smtp-Source: ABdhPJy3JtKgQ/I99bPJ2v8Uu3Ly/QyK1x4zk3xnVdGoV2mZP/gx/zpa6Vpt85o3U3RAc+RqtFFYWQ== X-Received: by 2002:a2e:544c:: with SMTP id y12mr440384ljd.4.1616434709116; Mon, 22 Mar 2021 10:38:29 -0700 (PDT) Received: from mail-lf1-f51.google.com (mail-lf1-f51.google.com. [209.85.167.51]) by smtp.gmail.com with ESMTPSA id q7sm1670827lfc.260.2021.03.22.10.38.28 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 22 Mar 2021 10:38:28 -0700 (PDT) Received: by mail-lf1-f51.google.com with SMTP id o126so13077355lfa.0 for ; Mon, 22 Mar 2021 10:38:28 -0700 (PDT) X-Received: by 2002:a05:6512:38d0:: with SMTP id p16mr257419lft.208.1616434708710; Mon, 22 Mar 2021 10:38:28 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Reply-To: joel@rtems.org From: Joel Sherrill Date: Mon, 22 Mar 2021 12:38:17 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: 64-bit Addresses in remote protocol To: Luis Machado Cc: gdb@sourceware.org X-Spam-Status: No, score=-3031.9 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS, HTML_MESSAGE, KAM_DMARC_STATUS, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Mar 2021 17:38:32 -0000 On Mon, Mar 22, 2021, 12:32 PM Luis Machado wrote: > Hi, > > On 3/22/21 1:55 PM, Joel Sherrill wrote: > > Hi > > > > Over at RTEMS, we are looking at some warnings in our debug > > server and wondering if fields described as "addr" in the gdb > > protocol should be treated 64-bits when that target has 64-bit > > addresses like the aarch64. > > If the inferior is using 64-bit addresses, then the remote protocol will > also use 64-bit addresses. If we have a 32-bit inferior running on > aarch64 hardware, we'll have 32-bit addresses over the remote protocol > as well. > > Even when we're using 64-bit addresses, the remote protocol may not pad > it with zeroes to make it 64-bit, but it should still be handled as 64-bit. > > Does that help? > I think it does. Sounds right to treat it as uintptr_t when decoding it. Unfortunately I think this means a review of our gdb server since it uses a decode uint method a lot and each case will need to be checked to see if it is called for an address. Was there somewhere in the gdb documentation this was and I missed it? My read of the protocol description focused on it as an ASCII command and not the types they mapped to. But I admit that I might have missed something. Thanks. --joel > > > > Technically, we are looking at sweeping through our gdb server > > and using uintptr_t for addresses where uint32_t has been > > ok before. > > > > But I wanted to make sure that our assumption that "addr" means > > a valid target address which means it can be 32- or 64- bits based > > on the target. > > > > Thanks. > > > > --joel > > RTEMS > > >