Re: time to workaround libc/13097 in fsf gdb?

[Pedro Alves <palves@redhat.com>]

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