From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21051 invoked by alias); 23 Sep 2014 11:49:48 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 21041 invoked by uid 89); 23 Sep 2014 11:49:47 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 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; Tue, 23 Sep 2014 11:49:47 +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 s8NBnikV023710 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 23 Sep 2014 07:49:44 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s8NBngla008349; Tue, 23 Sep 2014 07:49:42 -0400 Message-ID: <54215E55.5000408@redhat.com> Date: Tue, 23 Sep 2014 11:49:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: Jan Kratochvil CC: Doug Evans , "gdb-patches@sourceware.org" Subject: Re: time to workaround libc/13097 in fsf gdb? References: <20140922183505.GA21660@host2.jankratochvil.net> In-Reply-To: <20140922183505.GA21660@host2.jankratochvil.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2014-09/txt/msg00678.txt.bz2 On 09/22/2014 07:35 PM, Jan Kratochvil wrote: > On Sun, 21 Sep 2014 21:12:17 +0200, Pedro Alves wrote: >> Is it really a pain though? > > 95 lines of gdbarch.* patch + its ChangeLog is really a pain compared to 1 line of C++ virtual override. That is a different complain from the original "That's the pain of solib-svr4.c which is OS-agnostic and so it cannot find out start of the ELF file just from link map. gdbserver can find it as it can depend on /proc/PID/{s,}maps as its linux-low.c is Linux-specific." But still, well, that's a bogus comparison and you know that. You wouldn't get very far with just a 1 line... Even if GDB was written in C++, I'd probably still want to hook this through the gdbarch object, as it's a lower level thing than target_so_ops, which is consumed by add_vsyscall_table too. Most of those 95 lines include generated boilerplace that you'd need in C++ too. You'd need to count debug dump code, validation code, and the new entry point in the base object, and both the declaration and the definition of the override in the new class. It's actually quite possible to add a linux-specific target_so_ops that inherits svr4_so_ops, and we even do that for a few targets/archs). That's very much like the C++ virtual override, but even if we did that, istm we'd still make the new "class" use the new gdbarch method in its current_sos() method. I didn't do that as it doesn't seem worth it to add a new class for this, given that the gdbarch method returns false on the exact same set of targets that wouldn't use the new class, and then again, at some point, we may actually want to move the filtering of the vdso out close to where we already filter out a dso whose name is the same as of the executable, assuming it's the vdso. Yes, I know that C++ makes writing some of these things easier. No need to keep repeating it to me. The thing is that most of the design issues here are orthogonal to the C/C++ axis. And that shouldn't surprise, exactly because GDB is written in what some would call poor-man's C++-in-C style. Thanks, Pedro Alves