From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-f53.google.com (mail-wr1-f53.google.com [209.85.221.53]) by sourceware.org (Postfix) with ESMTPS id 9AAC4385701E for ; Thu, 27 Aug 2020 23:48:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 9AAC4385701E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=palves.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=alves.ped@gmail.com Received: by mail-wr1-f53.google.com with SMTP id d10so5998892wrw.2 for ; Thu, 27 Aug 2020 16:48:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=k73gTqXSlqJjZTiV8bDUUUnwhuXlgGq7y/P1NwhXwgw=; b=ALFAGXSJvK6MK+54MBPfWhq/PICww/MT7B9G96VgYcDbPXyNCKX3EROepKzMRllvmo tU4SLQAvgK3XUFMPaie6OIggdl1ltbitC0N1lD8wb7dBz42DpX7LMJ+hYqxH+cQArogs kS+AktbmL4y2zjz9nNpn4kfK9VoJqVQbYusX4xpEtdfOFqkl1ZUsFQ6Zxg4dwmCwLCd6 uVjNlyG+ztXrOs6/Ex8VLC+/zmD1NFlLdQyM8D7eIQbleQexR7NVmcIzLJnHCSrCzNNL zGrCk40oPFbWElLn60y1kGP5qO/B5tzhxqkeu6VrvDcYPLks5obstW9HhQZKUZcxa/c9 0JIw== X-Gm-Message-State: AOAM530GIZ6fz8G2U/Ytm5r0hMHA70YcaJ0wDBSxduIXJqrgBAQQiSYN uIpLLwWR3/W20k++zYnnAC3arWwGuch7Ag== X-Google-Smtp-Source: ABdhPJxTYzP7SD+TIXvQ/ciXm19ZeeOQ0A2Gutv1STXS2hySmGpSil7I3FaOvX9sSvp/P5qUSWkucg== X-Received: by 2002:a5d:5052:: with SMTP id h18mr23035656wrt.156.1598572109236; Thu, 27 Aug 2020 16:48:29 -0700 (PDT) Received: from ?IPv6:2001:8a0:f905:5600:56ee:75ff:fe8d:232b? ([2001:8a0:f905:5600:56ee:75ff:fe8d:232b]) by smtp.gmail.com with ESMTPSA id z14sm3877171wrh.14.2020.08.27.16.48.27 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 27 Aug 2020 16:48:28 -0700 (PDT) To: "gdb@sourceware.org" From: Pedro Alves Subject: A note about a GDB BoF topic - libgdbserver Message-ID: <61f8f765-8984-b6ce-8732-5f3e637492d7@palves.net> Date: Fri, 28 Aug 2020 00:48:27 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.6 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS, 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 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: Thu, 27 Aug 2020 23:48:33 -0000 Hi, On the GDB BoF @ LPC this week [1], we discussed the possibility of splitting gdbserver's core bits into a library so that other projects like valgrind, embedded stubs, simulators, etc. could reuse it. Licensing issues aside, the trouble as always is, who is going to do the work, is there someone motivated to do it? One thought that crossed my mind afterwards is a desire to change how GDB supports the sim. Instead of gdb's sim support being implemented by gdb linking with libsim.a, it would be better if we made the sim a separate gdbserver-like program that communicates with GDB via the remote protocol. That would allow for example connecting to multiple simulators at the same time, even different simulators of different architectures at the same time. That seems like a good excuse to move in the libgdbserver direction, and it doesn't even require thinking about licensing. Of course, another option would be to make gdbserver itself link with libsim.a -- make the sim another gdbserver backend. But that doesn't sound as cool. ;-) [1] https://www.youtube.com/watch?v=mMwC0QenvcA