From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16743 invoked by alias); 5 Aug 2017 08:00:47 -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 3325 invoked by uid 89); 5 Aug 2017 08:00:36 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=dying, snappy, screwing, dramatic X-HELO: mail-vk0-f47.google.com Received: from mail-vk0-f47.google.com (HELO mail-vk0-f47.google.com) (209.85.213.47) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 05 Aug 2017 08:00:34 +0000 Received: by mail-vk0-f47.google.com with SMTP id g189so12781057vke.5 for ; Sat, 05 Aug 2017 01:00:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=mAIpC3Z91DdjJ0K0Lu0A4psgTYpJYHtURz6wPu3qkEw=; b=W4hT35KI3yvJuGEk7vJckTygJZWv9kKfndNXb11HJ66KiuElVbk72w6na1sqK0kPCF KK8LXFby5QtIkOWoXHiS+ZeYPrIEac20YKpN42xNQzDkOBW1BkUTJey6RMPo5djZDxid sXR09IUIxrOttgO7W9DJL3D7ybEOx6kXMus4WhhTCDZnYH/uWOkQt3WPFZmI4BpB6grB yQgK574M83yWdZotUszRdq8jqFzm0MFHhBKMhaRwlz3kZ5EK5G+JKVFdL7OWIY+0wNRE Hhgbnx+hN1Fz1ec/Mdtio036Y3D3uXRqN8LtEMISu2DpV/US5xqe+E5IeThzaMjBbXta 5VMA== X-Gm-Message-State: AHYfb5j3anfRDifbZXYh1FJCZD6FT9rulUxE4iD0dv2TKMerf1MtvOUo 9nfx2soZcdSqcU2PGly9R+EjBGl6+Q== X-Received: by 10.31.102.133 with SMTP id a127mr2767597vkc.107.1501920029332; Sat, 05 Aug 2017 01:00:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.82.81 with HTTP; Sat, 5 Aug 2017 01:00:28 -0700 (PDT) In-Reply-To: <8360e3y0qc.fsf@gnu.org> References: <86d18b3732.fsf@gmail.com> <8360e3y0qc.fsf@gnu.org> From: Phi Debian Date: Sat, 05 Aug 2017 08:00:00 -0000 Message-ID: Subject: Re: Will GDB be rewritten in C++ (again) To: Eli Zaretskii Cc: Yao Qi , "gdb@sourceware.org" Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2017-08/txt/msg00012.txt.bz2 Hi All, Thank you for your replies. I am trying to see how I will move. The fact is that since epoch I was using GDB as a code base for some things I have never published, i.e my own things. One of them is having my own TUI not curses based but HPTERM based. HPTERM (like xterm but understand hp terminal esc sequence) has the ability of split an hard display in two with a feature called memory lock, the debugger can then manage and display sources in the memory locked area, while all the stdio flaw is still directed to the tty, doing a 'windowing' at low cost and at a very low protocal over head (compared to ddd, or the sloppines of the tui with stdout screwing uo the soruce area) My own TUI is so easy to do I just peek poke an a few GDB function, the main() is mine and my code is C, how to make this happen with C++ I dunno. I also leaverage some GDB code to do my own lib, actually more than GDB I need a libgdb, not the one that has been tried over and over, but mine, to do programatical debugger, all this assume the code to be C not C++. A programatic debugger is as debugger that is actually a lib, and the main() is a C tool linked with the lib and can then programtically use API's to unwind functions, retrieve args, walk on the core, access struct/union member in a efficient way i.e C speed. As another example of the problematic, long time ago I needed to have a stack unwinder for ia64, the only one existing was C++, i had to write my own then in C, and frankly there was no reasons this unwinder was developped in C++ up front. I think I got tons of examples that way, another that come in mind is the snappy compressor, some linux kernel crash use this compressor, and the decompressor was written whence in C++ until someone pest of did it in C, simple and easy, that's the one I use. I need stuff like libelf, libdwarf, when I say lib* it could be GDB code extracted, and if all that is moving to C++ that mean I got to make it C somewhere. So I dunno yet where to stand, may be accept the C era is behind me, I got my time on it, and may be it is time to go apple picking, fishing, enjoy life :) I still think there are big big application out there written in C, linux kernel for instance, and my debugger (not GDB but using some GDB parts) is aimed at BIG BIG application debbuging, mostly on crash (core, vmcore) but on live as well, and digging into this huge core is not doable with GDB, because we are talking here walking on gigantic data structure, and automate the sorting of it, think for instance a memory leak in a kernel crash, tons of mblock from various bucket, you want to load them all (million) and corelate them with other thing to somewhat figure out the good ones and the leaked ones, etc, this can not be done by any interperted interaction with GDB, it just don't scale, so no sial, no pkdump can do that. I do that with C access to the crash and the processing is done at C speed over the dump. So no need to say that gdb++ impairs my work. As for the 'dramatic' level :) i.e the threshold when a C code got to be moved to C++, I would say that the very basic low level should be C with C namespace for the one who wants its acessible in C++, and keep the low level source pure C so extractable for other. For instance use a lot of the disasm code, I can extract it from the GDB source get rid of the BFD dependencie and be selfsufficient, with the C++ move I can't do that anymore. Luckillly this is pretty stable and I don't see new architecture comming, I see more architecture dying, so the snapshot of the GDB source at 7.x is good enough, but I would say the future of hacking inthe GDB get darker :) I think GDB fall in the trap the "LLVM do it C++ they must my right..." May be (I am not in the GDB internals) so may be GDB C++ is need for doing C++ debugging ?, so for the good old C that it is still in use, may be a lighter debugger (CDB?) forked from GDB7.x could be good enough, because may be C will not evolve much, and then the CDB would be easy to maintain, i.e backporting some stuff from GDB++ like say ptrace() update could be easy to do. Well I will give it some toughts. Cheers, Phi