aboutsummaryrefslogtreecommitdiff
path: root/gdb/tracectf.c
diff options
context:
space:
mode:
authorAndrew Burgess <aburgess@redhat.com>2023-02-27 13:47:10 +0000
committerAndrew Burgess <aburgess@redhat.com>2023-07-07 15:20:28 +0100
commit1a36815e2f1ad39acf894660759cf1a0bef39fcc (patch)
tree5e4e114c1fcd5e12d1ec5c50089c380581b95ed6 /gdb/tracectf.c
parentbde240e7f83f208568254574082df12c871dcbc8 (diff)
downloadgdb-1a36815e2f1ad39acf894660759cf1a0bef39fcc.zip
gdb-1a36815e2f1ad39acf894660759cf1a0bef39fcc.tar.gz
gdb-1a36815e2f1ad39acf894660759cf1a0bef39fcc.tar.bz2
gdb: remove two uses of alloca from printcmd.c
Remove a couple of uses of alloca from printcmd.c, and replace them with gdb::byte_vector. An earlier variant of this patch was proposed in this thread: https://inbox.sourceware.org/gdb-patches/cover.1677533215.git.aburgess@redhat.com/ however, there was push back on that thread due to it adding extra dynamic allocation, i.e. moving the memory buffers off the stack on to the heap. However, of all the patches originally proposed, I think in these two cases moving off the stack is the correct thing to do. Unlike all the other patches in the original series, where the data being read was (mostly) small in size, a register, or a couple of registers, in this case we are reading an arbitrary string from the inferior. This could be any size, and so should not be placed on the stack. So in this commit I replace the use of alloca with std::byte_vector and simplify the logic a little (I think) to take advantage of the ability of std::byte_vector to dynamically grow in size. Of course, really, we should probably be checking the max-value-size setting as we load the string to stop GDB crashing if a corrupted inferior causes GDB to try read a stupidly large amount of memory... but I'm leaving that for a follow on patch. There should be no user visible changes after this commit.
Diffstat (limited to 'gdb/tracectf.c')
0 files changed, 0 insertions, 0 deletions