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 CB97C3858CDB for ; Fri, 8 Dec 2023 13:06:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org CB97C3858CDB Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org CB97C3858CDB Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1702040796; cv=none; b=vIjLX6EtgzG5gE3xHwOHP1wnMleAEK7wZ3aylW/fRMxUhm5aDEfGblWrnpq7m9E7VdeEv27A3zDBWdOs3z400TcPcLXpLwtoCQK8w5ak79Zrf9iehy9QLsiOZeB3K798BhA+TTMCd7XfcWgD/ETKUUoh8qQ9StsuLUM5nYh2thc= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1702040796; c=relaxed/simple; bh=aUrlL9C2eoicZNEY0HvRzqLdWR4MVHPUQa6t5hJP3Ag=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=ZP4BF1GDCjdIi8Y6l5091vDcfQiyQHygLlyuOJ+tLdnEI7LmDehONAi3nb984idwDQxMkJPON6FtUWt6sJgH8FkJleRiUutp82AAmjJPVhqkz7axDWCBM87hBMy201wiVw/5rUHR0bIHAoMgbFOpfLGioDr2AYVQ8tbAaYck1Ng= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1702040785; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=nuecaGA94856xSyDPcx9McqG67rkYOUKgXgn7FJSikQ=; b=GLrVaq3Hh28ey+5GzQbzR1uJCjeRc4z8bmjGT8Ef/7y1ZLgBH6j0bJytQo8hRLe1eaDzlj ocMT96v8acOA02zRq5cpm2fapzaTWd5D5f606FH8eWsgmtF9ndG8ks/z5SuQ0x7SZlkWN3 tRDaRi8M9ybkU9Fquo0JeGY1HddE9Ec= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-323-TZaEhuk7MzqRwfCS_FTknw-1; Fri, 08 Dec 2023 08:06:23 -0500 X-MC-Unique: TZaEhuk7MzqRwfCS_FTknw-1 Received: by mail-wm1-f72.google.com with SMTP id 5b1f17b1804b1-40b53e5fc6bso14139635e9.3 for ; Fri, 08 Dec 2023 05:06:22 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702040782; x=1702645582; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=nuecaGA94856xSyDPcx9McqG67rkYOUKgXgn7FJSikQ=; b=REbvVlr7O5F3Pnzq+2b2K/gQk1KS5JoTQjoslCg5Lvr6S1Hi4mM8AMnHsIuF5xcPJY coFWp4X/TM5NJH91qmEA6PrRBvIvOZbDNM791j7WExl5F2Y6fmvjVLxrjr/Uo4JkVMfJ JFlYGx9xj8tXH2wjyYUMzfW2zTnSm4JTE/vngS+86BFgvqto5lppiz7gnsTO7h3ZgWua uhvB3xQT9QOByHRs+bbLUudkGcsIW6ch0sQpo3DG9IO5o0DeHxCgMKccl7MorWFycAhs 6sOH/3UAJvQQnOoL3dkfnL3fr9MmzuwM9iZfQ7vDTy6mzJ2StDoLlQ5SmzKGsUIULQZ4 y88g== X-Gm-Message-State: AOJu0YyZAM3aIS3c9FLoPutgxH4uBNhLLBbdA7j0cT7WgUSBJDqiariw G4mxkJwdN1MhroF5yi4XGP4vP6t+04faUtKwDdqOOXYZy4JyQTCLGk78PZaUqNBFqO4c7DjoUms rIzBMGY5GjNCeitXQb9Z3QA== X-Received: by 2002:a05:600c:1f15:b0:40c:2d4f:496f with SMTP id bd21-20020a05600c1f1500b0040c2d4f496fmr1149996wmb.112.1702040781998; Fri, 08 Dec 2023 05:06:21 -0800 (PST) X-Google-Smtp-Source: AGHT+IEBN1jzxf2L20zquXbxGKDH7fmn9AVKrb7+5QYG4ec3tQfav8jcynZT2kh0c7npQ9cUb6lFmw== X-Received: by 2002:a05:600c:1f15:b0:40c:2d4f:496f with SMTP id bd21-20020a05600c1f1500b0040c2d4f496fmr1149986wmb.112.1702040781660; Fri, 08 Dec 2023 05:06:21 -0800 (PST) Received: from localhost (105.226.159.143.dyn.plus.net. [143.159.226.105]) by smtp.gmail.com with ESMTPSA id o3-20020a05600c4fc300b004042dbb8925sm5096538wmq.38.2023.12.08.05.06.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 08 Dec 2023 05:06:21 -0800 (PST) From: Andrew Burgess To: Tom Tromey , Alexandra Petlanova Hajkova Cc: Tom Tromey , gdb-patches@sourceware.org Subject: Re: [PATCH 0/6] Add vDefaultInferiorFd feature In-Reply-To: <87zfyok5bk.fsf@tromey.com> References: <20231117111840.2040709-1-ahajkova@redhat.com> <874jh1brln.fsf@tromey.com> <87zfyok5bk.fsf@tromey.com> Date: Fri, 08 Dec 2023 13:06:20 +0000 Message-ID: <87zfykg7xv.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.7 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,T_SCC_BODY_TEXT_LINE 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: Tom Tromey writes: >>>>>> "Alexandra" == Alexandra Petlanova Hajkova writes: > >> Another approach might be to have a different way to specify the >> connection fd to the remote, like a command-line option naming the fd to >> use for RSP traffic. > > Alexandra> Are you imagining something like "target remote | gdbserver --once RSP_FD ...." ? > Alexandra> And GDB would replace RSP_FD with the actual file descriptor to use? > > Yeah. There is one problem I see with this approach, maybe a bit of an edge case, but, what if the application wanted to use the text RSP_FD elsewhere in it's command line. For example, a user does: (gdb) target remote | gdbserver --once RSP_FD /tmp/myprog And everything is great, GDB replaces RSP_FD with the descriptor to use for RSP traffic, and that's fine. Or a user does: (gdb) target remote | gdbserver --once /tmp/myprog And GDB doesn't spot RSP_FD, so doesn't redirect the RSP traffic, and just continues to use stdin/stdout as it does right now. But what about the poor user who needs to do this: (gdb) target remote | gdbserver --once /tmp/myprog RSP_FD that is the 'RSP_FD' is an actual argument string to pass to 'myprog'! Unlikely maybe, but not impossible. Anything that requires GDB to understand the command that appears after the `|` suffers from the possibility that GDB might get it wrong. > > Alexandra> avoids adding a new packet and the whole FD switching business. But adding the new > Alexandra> packet approach makes it easier for the users. It's possible to run GDB to then run > Alexandra> Valgrind from inside by using simply > > Alexandra> target extended-remote | vgdb --multi > > Alexandra> I hope this command will be replaced with an even simpler " target valgrind" at > Alexandra> some point. > > Part of the idea would be to hide the new file descriptor handling > behind the "target valgrind" facade. That is, the implementation of > "target valgrind" would handle setting up the command line arguments to > vgdb. Even writing a Python wrapper doesn't really solve the above problem, it just shifts it from GDB into the Python code. And (I think) ideally we wouldn't rely on users having to write a Python wrapper in order to use this feature with their own tools, so it would be nice if this feature was usable from pure GDB. Maybe it's just enough to add an on/off control setting, and have GDB announce when it's performed the command line replacements. Then (hopefully) users will know that if they don't want this feature they could turn this off... Just my thoughts. Thanks, Andrew