From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 102649 invoked by alias); 19 Feb 2020 17:42:15 -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 102529 invoked by uid 89); 19 Feb 2020 17:42:14 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=lx, UD:Tpo X-HELO: us-smtp-1.mimecast.com Received: from us-smtp-delivery-1.mimecast.com (HELO us-smtp-1.mimecast.com) (205.139.110.120) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 19 Feb 2020 17:42:12 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1582134131; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=0SI0CJOymkdYRAc3bsX6KQBy6QIhHYUxxkXh3YW0Has=; b=hR0VYglggWB6lcsWxrsztw4uuCTY44HwURxGSh7Wzv+qoVzOcpimaruKRykt0CAM6+3V1F ChGgfF7H7Il8tL4ZjyCnBcxSvFWM72Hrmzm8geqQ+Yd9FwHE/f8/uKvTPXjHyEXz2TeoOY OwW/M6TP+zuPODZUyjjiy1BmRvflB6E= 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-162-3wFHwZIlNM-NPoWKoBac3Q-1; Wed, 19 Feb 2020 12:42:09 -0500 Received: by mail-wr1-f72.google.com with SMTP id a12so416796wrn.19 for ; Wed, 19 Feb 2020 09:42:09 -0800 (PST) Return-Path: Received: from ?IPv6:2001:8a0:f909:7b00:56ee:75ff:fe8d:232b? ([2001:8a0:f909:7b00:56ee:75ff:fe8d:232b]) by smtp.gmail.com with ESMTPSA id o2sm628497wmh.46.2020.02.19.09.42.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 19 Feb 2020 09:42:06 -0800 (PST) Subject: Re: [PATCH] Change gdbserver to use existing gdbsupport To: Tom Tromey , gdb-patches@sourceware.org References: <20200219170643.10725-1-tom@tromey.com> From: Pedro Alves Message-ID: <48984f7d-f851-84c8-1145-95fbfbbade23@redhat.com> Date: Wed, 19 Feb 2020 17:42:00 -0000 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: <20200219170643.10725-1-tom@tromey.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-SW-Source: 2020-02/txt/msg00788.txt.bz2 On 2/19/20 5:06 PM, Tom Tromey wrote: > This changes the gdbserver build to use the gdbsupport that was built > for gdb. >=20 > The most notable change here is that CORE_ADDR is always a 64-bit > type. This makes it so that gdb acts as if it were always built in > 64-bit mode. >=20 > I tested this locally, and I tried it with a few crosses using > AdaCore's internal test suite (including a 32-bit build). However, I > don't have a very clear idea of what code might break due to the > switch from a 32- to 64-bit CORE_ADDR. I'm surprised you didn't hit any problem, because last time we chatted about it, I quickly tried it, and ran into a small number of places that needed adjustment. I just tried it again, and I get, for example, with a i686-pc-linux-gnu build: $ make V=3D1 remote.o g++ -m32 -x c++ -g3 -O0 (....) -c -o remote.o -MT remote.o -MMD -MP -MF ./= .deps/remote.Tpo /home/pedro/gdb/binutils-gdb/src/gdb/remote.c In file included from /home/pedro/gdb/binutils-gdb/src/gdb/defs.h:37:0, from /home/pedro/gdb/binutils-gdb/src/gdb/remote.c:22: /home/pedro/gdb/binutils-gdb/src/gdb/remote.c: In member function =E2=80=98= virtual void remote_target::download_tracepoint(bp_location*)=E2=80=99: ../bfd/bfd.h:198:62: error: format =E2=80=98%lx=E2=80=99 expects argument o= f type =E2=80=98long unsigned int=E2=80=99, but argument 3 has type =E2=80= =98CORE_ADDR {aka long long unsigned int}=E2=80=99 [-Werror=3Dformat=3D] #define sprintf_vma(s,x) sprintf (s, "%08" BFD_VMA_FMT "x", x) ^ /home/pedro/brno/pedro/gdb/binutils-gdb/src/gdb/remote.c:12817:3: note: in = expansion of macro =E2=80=98sprintf_vma=E2=80=99 sprintf_vma (addrbuf, tpaddr); ^~~~~~~~~~~ /home/pedro/gdb/binutils-gdb/src/gdb/remote.c: In member function =E2=80=98= virtual void remote_target::enable_tracepoint(bp_location*)=E2=80=99: ../bfd/bfd.h:198:62: error: format =E2=80=98%lx=E2=80=99 expects argument o= f type =E2=80=98long unsigned int=E2=80=99, but argument 3 has type =E2=80= =98CORE_ADDR {aka long long unsigned int}=E2=80=99 [-Werror=3Dformat=3D] #define sprintf_vma(s,x) sprintf (s, "%08" BFD_VMA_FMT "x", x) ... If I use "make -k", I run into a few more like the above in two or three more files. I'd prefer to see this conversion in two separate patches. One (or more) t= hat removes the bfd dependency from gdb's gdbsupport, which potentially is a ma= terial change for making GDB always use 64-bit types, and then a separate change to make gdbserver use top level gdbsupport. Thanks, Pedro Alves