This is the mail archive of the
mailing list for the GDB project.
Re: time to workaround libc/13097 in fsf gdb?
- From: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- To: Pedro Alves <palves at redhat dot com>
- Cc: Doug Evans <xdje42 at gmail dot com>, "gdb-patches at sourceware dot org" <gdb-patches at sourceware dot org>
- Date: Sun, 28 Sep 2014 15:41:19 +0200
- Subject: Re: time to workaround libc/13097 in fsf gdb?
- Authentication-results: sourceware.org; auth=none
- References: <20140922183505 dot GA21660 at host2 dot jankratochvil dot net> <54215E55 dot 5000408 at redhat dot com>
On Tue, 23 Sep 2014 13:49:41 +0200, Pedro Alves wrote:
> 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.
> But still, well, that's a bogus comparison and you know that.
No; or in part - just that 95 was counted with diff context, 1 without context.
> Even if GDB was written in C++, I'd
> probably still want to hook this through the gdbarch object,
Irrelevant, "gdbarch" probably would not exist with cheap-OO language.
> 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.
Maybe 2-3 lines, not 1. That is not important.
> The thing is that most of the design issues here are orthogonal to the C/C++