From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qv1-xf33.google.com (mail-qv1-xf33.google.com [IPv6:2607:f8b0:4864:20::f33]) by sourceware.org (Postfix) with ESMTPS id E1EBA3858004 for ; Mon, 22 Mar 2021 17:52:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org E1EBA3858004 Received: by mail-qv1-xf33.google.com with SMTP id g8so9108061qvx.1 for ; Mon, 22 Mar 2021 10:52:08 -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:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=/k6Z+zNSaE9kmLrG835CYDaDAal47locWsor2SH3eLg=; b=UbB4UHbsvMPs/frXW/fH97KMwhnkoq8xkchPd0aYPLw7frBz7VP3lYx6xlBGK1vmDz HrnryHlc2sgz6aVAIdM5h+FLatmCy5KU02LMbtjeZf9zqANvTaZPFMcDXehc41dEuypu y6jC4ByyjiM6pBXHlnRB+DhPldOyIfkgwWfb6jDEsRsuj4CIwy7T5wyNh1c2L7bDxQ/2 fCExmwKvJ8IwBPZ+1+RCsbfQ7IW/aUQOUyDEAXldvd+rXNz0QePxuCdpCi0/8LYNcCbv WiOmr4yFctlYZjtlfY2DtYD+Aw2qJO/J3A8LXOMcoCeySphSiBtvgBumChTbeebu8LkU 13zg== X-Gm-Message-State: AOAM531kZipwOCAtXov3FO7960BkF9zCBA8w6lwAKc8HpgDdRtXggSrh J/ugMyfxT8U/9N7+eZtfnVKJNBRUC0Taug== X-Google-Smtp-Source: ABdhPJycZobf/AAyACI+GAw9s5FHG5aftDq6nEFMAZy0BQA1UtmpfNLflLnEsVVZf/ZQhM4uD8o2ug== X-Received: by 2002:a0c:8121:: with SMTP id 30mr779352qvc.27.1616435528465; Mon, 22 Mar 2021 10:52:08 -0700 (PDT) Received: from ?IPv6:2804:7f0:4841:2841:2c21:ec8a:30f3:55a6? ([2804:7f0:4841:2841:2c21:ec8a:30f3:55a6]) by smtp.gmail.com with ESMTPSA id q15sm9240382qtx.47.2021.03.22.10.52.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 22 Mar 2021 10:52:08 -0700 (PDT) Subject: Re: 64-bit Addresses in remote protocol To: joel@rtems.org Cc: gdb@sourceware.org References: From: Luis Machado Message-ID: <16885a27-dd01-dc64-1201-8eacb49b7a72@linaro.org> Date: Mon, 22 Mar 2021 14:52:05 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-6.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, 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@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:52:10 -0000 On 3/22/21 2:38 PM, Joel Sherrill wrote: > > > 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. Can you switch to decoding 64-bit values by default and casting to 32-bit when necessary? > > 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. I don't think so. This is all more or less implicit and there doesn't seem to be any formal documentation about what "addr" in the remote protocol should look like. For example, there are packets that refer to "addr" as an address and nothing more. Some others, like 't', tell us something more: "There must be at least 3 digits in addr". So, unfortunately, there isn't a standard way addr should be formatted. But most of the uses match the inferior's address size. > > 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 > > >