This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
[PATCH 0/3] Introduce gdb::array_view, symtabs_and_lines -> std::vector
- From: Pedro Alves <palves at redhat dot com>
- To: gdb-patches at sourceware dot org
- Date: Mon, 21 Aug 2017 20:27:44 +0100
- Subject: [PATCH 0/3] Introduce gdb::array_view, symtabs_and_lines -> std::vector
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx10.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx10.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=palves at redhat dot com
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 2849F61469
Looking at the "list and multiple locations" patch [1], I thought that
it's a bit annoying/frustrating to have do remember to free the sals
array that a symtabs_and_lines object wraps, with 'xfree (sals.sals)'
or the equivalent make_cleanup(xfree, ...), not to mention how
error-prone manual memory management is. We can do better in C++.
So I wrote a patch to replace 'struct symtabs_and_lines' with 'typedef
std::vector<symtab_and_line> symtabs_and_lines'. That works nicelly,
except that I wasn't entirely happy that that would introduce heap
allocations in a few cases where there is none nowadays.
I then addressed that by adding an array_view abstraction, which is
something that I've wanted at other times before.
After that, we'd end up with some places using a std::vector disguised
behind the symtabs_and_lines typedef, while in other places we'd be
spelling out gdb::array_view. With that, I no longer see any value in
keeping the symtabs_and_lines typedef, kind of giving preference to
std::vector, so I removed the typedef, choosing to spell out
std::vector explicitly.
(I'm aware that there are several proposals for adding something like
array_view to the standard C++ library. In this implementation, which
was written from scratch and developed in parallel with the unit
tests, I chose to keep it as simple and safe as possible. For
example, there is no support for ranks != 1, simply because the main
use case this aims at addressing is abstracting out std::vector vs
stack arrays in APIs.)
[1] https://sourceware.org/ml/gdb-patches/2017-07/msg00280.html
Note that the net increase shown below is mostly caused by the new
unit tests. If we only count patches 2 and 3, then we get instead:
33 files changed, 537 insertions(+), 820 deletions(-)
Pedro Alves (3):
Introduce gdb::array_view
struct symtabs_and_lines -> std::vector<symtab_and_line>
Kill init_sal
gdb/Makefile.in | 2 +
gdb/ada-lang.c | 3 +-
gdb/ax-gdb.c | 12 +-
gdb/break-catch-throw.c | 12 +-
gdb/breakpoint.c | 359 +++++++++++--------------
gdb/breakpoint.h | 20 +-
gdb/cli/cli-cmds.c | 158 +++++------
gdb/common/array-view.h | 179 +++++++++++++
gdb/elfread.c | 14 +-
gdb/frame.c | 25 +-
gdb/frame.h | 3 +-
gdb/guile/scm-frame.c | 2 +-
gdb/guile/scm-symtab.c | 6 +-
gdb/infcall.c | 11 +-
gdb/infcmd.c | 35 +--
gdb/infrun.c | 52 ++--
gdb/linespec.c | 264 ++++++++-----------
gdb/linespec.h | 32 +--
gdb/macrocmd.c | 8 +-
gdb/mi/mi-main.c | 17 +-
gdb/probe.c | 33 +--
gdb/probe.h | 14 +-
gdb/python/py-frame.c | 3 +-
gdb/python/python.c | 47 ++--
gdb/reverse.c | 8 +-
gdb/source.c | 54 ++--
gdb/source.h | 3 +-
gdb/stack.c | 56 ++--
gdb/stack.h | 2 +-
gdb/symtab.c | 26 +-
gdb/symtab.h | 27 +-
gdb/tracepoint.c | 39 +--
gdb/tui/tui-disasm.c | 2 +-
gdb/tui/tui-stack.c | 3 +-
gdb/tui/tui-winsource.c | 7 +-
gdb/unittests/array-view-selftests.c | 489 +++++++++++++++++++++++++++++++++++
36 files changed, 1207 insertions(+), 820 deletions(-)
create mode 100644 gdb/common/array-view.h
create mode 100644 gdb/unittests/array-view-selftests.c
--
2.5.5