Re: [PATCH 2/2] gdb: use std::vector<> to hold on blocks in struct blockvector

[Simon Marchi <simark@simark.ca>]

On 10/14/25 4:05 PM, Tom Tromey wrote:
>>>>>> "Simon" == Simon Marchi <simark@simark.ca> writes:
> 
> Simon> I also wish we could avoid having a "set_block" method, because it
> Simon> requires having the blockvector in an invalid state (some blocks slots
> Simon> set to nullptr) while we build it, which could be error prone.  The
> Simon> users of the set_block method are buildsym and jit.  From what i saw,
> Simon> they could both very well prepare an std::vector with their blocks and
> Simon> std::move that vector into a blockvector constructor.  That constructor
> Simon> could assert that the blocks are correctly ordered, or to the sort
> Simon> itself (something that both buildsym and jit do already).  buildsym
> Simon> starts with a singly-linked list (m_pending_blocks), moves the blocks to a
> Simon> temporary vector (in end_compunit_symtab_get_static_block), sorts that
> Simon> vector, builds a singly-linked list again, and then traverses that list
> Simon> to insert the blocks into the blockvector.  I think that could all be
> Simon> simplified by making m_pending_blocks an std::vector<block *> from the
> Simon> start.
> 
> Are you proposing that Jan do this in this patch?  Or is this just a
> future-looking comment?  It wasn't clear to me.
> 
> Tom

Sorry about that.  I would not ask Jan to refactor or clean up
everything in buildsym and jit.  But perhaps we can agree on what a good
(easy to use, hard to mis-use) API for blockvector is, and then Jan can
do the bare minimum to wire up buildsym and jit to that API.  We can
then do some cleanups later to remove some unnecessary steps in buildsym
and jit.

Simon