From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12017 invoked by alias); 17 Oct 2014 12:02:58 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 12006 invoked by uid 89); 17 Oct 2014 12:02:58 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.0 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Fri, 17 Oct 2014 12:02:56 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s9HC2sNw028805 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 17 Oct 2014 08:02:54 -0400 Received: from host2.jankratochvil.net (ovpn-116-79.ams2.redhat.com [10.36.116.79]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s9HC2o3w019243 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NO); Fri, 17 Oct 2014 08:02:53 -0400 Date: Fri, 17 Oct 2014 12:02:00 -0000 From: Jan Kratochvil To: Stan Shebs Cc: gdb@sourceware.org Subject: Re: GDB C API -- does such a thing exist? Message-ID: <20141017120250.GB7123@host2.jankratochvil.net> References: <5440588D.8060503@earthlink.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5440588D.8060503@earthlink.net> User-Agent: Mutt/1.5.23 (2014-03-12) X-IsSubscribed: yes X-SW-Source: 2014-10/txt/msg00063.txt.bz2 On Fri, 17 Oct 2014 01:45:17 +0200, Stan Shebs wrote: > The fact of the situation is that a C API would make things harder, not > easier. Consider that GDB is a) making system calls, which are > sometimes blocking, b) is doing tricks with signals all over the place, Yes but those are cornercases. > and c) gets involved with permissions, I do not see what you mean there. > and d) manages vast quantities of memory. What's the problem with multi-process vs. single-process solution? The problem is that GDB corrupts memory as it is not written in C++. I was trying to switch GDB to C++ which was rejected and then I at least posted some -fsanitize=address patches which were ignored. > MI is really the safe way to go. The problem with MI is that there is (AFAIK) still no good enough client library and primarily MI implements only very poor subset of GDB functionality so one has to use '-interpreter-exec console ...' anyway and parse the unparsable text output. Thanks but C API is much easier (C++ would be sure even easier). LLDB has C++ API but that can never work well for GDB due to GPL of GDB. Jan