From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 64EC93858C2B for ; Wed, 20 Sep 2023 12:59:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 64EC93858C2B Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1695214791; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=nNYv5KnhGWGtv0wFaNS74tCCYk0lkE9eJWhhGTVNT00=; b=RwoG7CofiprjOWSv2O5t4Xv85/IyXB5jVWKSzHZ3qAfZJe7wrcRL6s1qhng8yJCT26MTkp N0gGWUqUwhBdfG7Y35X1/0ses1ecG2hFs7BXJuJmYbdTcUb9i22k2j/PbO9UhV9NPhgXpj mHcniBy3vqLlEw7Wq5WR6U/HbjD49+k= Received: from mail-ej1-f72.google.com (mail-ej1-f72.google.com [209.85.218.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-39-6aIuwe3AMV24UAYWjwzi9w-1; Wed, 20 Sep 2023 08:59:49 -0400 X-MC-Unique: 6aIuwe3AMV24UAYWjwzi9w-1 Received: by mail-ej1-f72.google.com with SMTP id a640c23a62f3a-993d7ca4607so510060466b.1 for ; Wed, 20 Sep 2023 05:59:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695214788; x=1695819588; h=mime-version:message-id:date:references:in-reply-to:subject:to:from :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=nNYv5KnhGWGtv0wFaNS74tCCYk0lkE9eJWhhGTVNT00=; b=EIKgi2Ansim3+47SlgfVXg8RmSs8C2h0NXSB7eaRPOgxLpePp82xZARnbIWPka1exh XrfovhwvSp3k/2oUMiUZooXtwjsURh+B0wYMmP6bOdD+74TU1KMmXsazFscFGzJhGsoK deVLlHqN3fuBla5OnHrd+Iaj8fDxWlGX3MFnoc1+dK0VkmFipi871h+eWK4jjyOEN0A2 acYmql1cAGxCz+G02qGimYGsyQh0lK/JO4qh0qucHvpUihQmjbQcbehvTB1I3qZWi4Cm tlP76D6s+49lJQEHwaMZflwi57cvwsvQ1TuPzF4IYoXf7c4uQu9b0G64VWUhDYQmJfGI n4DQ== X-Gm-Message-State: AOJu0Yzo3pkCZca7qzGdbmR3Oi2qj/4jX14K/El2u+5kBWrLNF7Xnp6b UXq55lFTnCNlosEo/N6Dd7hlGInxcqaLghoG9Il4iwvw/66iKNJJckyqQLUsySWnW8EOQMclZyn 4bjgRJF2WcZIhmO9mO0kA5uI/9vmJAg== X-Received: by 2002:a17:906:159:b0:9a1:f21e:cdff with SMTP id 25-20020a170906015900b009a1f21ecdffmr2322032ejh.23.1695214788442; Wed, 20 Sep 2023 05:59:48 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFmqxGGH+OLIbbNykzioxBZEcp/O2fW+l0Zr8yl1Lir8RlsyhsqaTSF6kUd4mILGJyqkj+dNg== X-Received: by 2002:a17:906:159:b0:9a1:f21e:cdff with SMTP id 25-20020a170906015900b009a1f21ecdffmr2322017ejh.23.1695214788106; Wed, 20 Sep 2023 05:59:48 -0700 (PDT) Received: from localhost ([31.111.84.209]) by smtp.gmail.com with ESMTPSA id mh25-20020a170906eb9900b0099297782aa9sm9256147ejb.49.2023.09.20.05.59.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 20 Sep 2023 05:59:47 -0700 (PDT) From: Andrew Burgess To: "Gerlicher, Klaus" , Simon Marchi , "gdb-patches@sourceware.org" Subject: RE: [PATCH 1/1] gdb, gdbserver: replace PBUFSIZ with a target op In-Reply-To: References: <20230919054511.17998-1-klaus.gerlicher@intel.com> <20230919054511.17998-2-klaus.gerlicher@intel.com> <3d0d3efc-f802-4a3a-a602-dc3e59c99c94@polymtl.ca> Date: Wed, 20 Sep 2023 13:59:46 +0100 Message-ID: <87sf79xanx.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-5.5 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_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: "Gerlicher, Klaus via Gdb-patches" writes: > Hi Simon, > > Thanks for the quick response. > > At least the initial buffer size needs to be fixed since now most > clients aren't aware of any dynamic behavior here and therefore we > need at least something pre-allocated for these clients. I don't understand your concerns here. For this patch we're only talking about the gdbserver client, right? And your patch (rightly) doesn't change things on the GDB side. GDB already uses a dynamic packet buffer size. So the only initial buffer I think you can be talking about here is the gdbserver buffer, which I think could be made dynamic, just as GDB's is. We could hard-code gdbserver to return some stupidly large number for the PacketSize in the qSupported reply, say MAX_INT? Or (MAX_INT / 4), you pick, this could be anything really, just something huge. Then on the gdbserver side we can use a dynamic packet size, and we just take care to throw an error if GDB ever tries to grow it past our (stupidly large) max packet size -- but this doesn't mean we actually need to pre-allocate that large of a buffer. Alternatively, we can always extend the remote protocol with a new reply, say 'PacketSize=*' to indicate that the client supports variable packet buffers -- but that would require GDB to first advertise that it understands that syntax, then clients will need to deal with GDBs that don't support it .... and it's a whole big thing. Maybe easier just to work within the current framework? Though maybe not as clean. Now for other clients (i.e. not gdbserver) they are free to keep using a pre-allocated buffer, and they'll send back a much smaller PaketSize, but that should be fine. Nothing changes for them. > For the clients interested we could change the CS buffer to a > re-allocatable type that is pre-allocated with the current PBUFSIZ. We > could pass this buffer around with a target op. The target could > resize at will instead of letting it return a fixed number. I didn't understand this paragraph. I don't know what 'CS buffer' means. And I'm not sure why we're need a target op to pass the buffer around -- but maybe that would become obvious if I looked at the code a little more... Thanks, Andrew > > Is this something in line that you would support? > > Klaus > > -----Original Message----- > From: Simon Marchi > Sent: Tuesday, September 19, 2023 4:08 PM > To: Gerlicher, Klaus ; gdb-patches@sourceware.org > Subject: Re: [PATCH 1/1] gdb, gdbserver: replace PBUFSIZ with a target op > > On 9/19/23 01:45, Klaus Gerlicher via Gdb-patches wrote: >> From: "Gerlicher, Klaus" >> >> PBUFSIZ is a hardcoded value that needs to be as least twice as big as >> the register set. >> >> This means that this could be tailored to the target register size as >> not all targets need a big buffer. For SIMD targets the buffer will >> obviously be much bigger than for regular scalar targets. >> >> This patch changes this and adds a target op query_pbuf_size (). It >> also moves the static global client_state into the get_client_state () >> function and lazily dynamically allocates storage for its own_buf. > > Just throwing an idea out there... instead of trying to determine a buffer size that is large enough, can we instead pass something like an std::vector (gdb::char_vector or gdb::byte_vector) around, and whatever builds the packets and replies makes sure there is enough space? > > Simon > Intel Deutschland GmbH > Registered Address: Am Campeon 10, 85579 Neubiberg, Germany > Tel: +49 89 99 8853-0, www.intel.de > Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva > Chairperson of the Supervisory Board: Nicole Lau > Registered Office: Munich > Commercial Register: Amtsgericht Muenchen HRB 186928