Re: [PATCHv3] Fix range end handling of inlined subroutines

[Bernd Edlinger <bernd.edlinger@hotmail.de>]

On 3/19/20 2:33 AM, Bernd Edlinger wrote:
> On 3/17/20 11:27 PM, Andrew Burgess wrote:
>>
>> Are you arguing that we shouldn't use std::vector anywhere in GDB?  Or
>> that this particular piece of code shouldn't use std::vector?
>>
> 
> No, in general std::vector is just fine.
> I think just here it is especially important to be below O(n*log(n)),
> and don't depend on the underlying implementation.
> 
>> It was my understanding that we were moving GDB away from bespoke
>> container management code unless there was a very compelling reason.
>> I think as a minimum any new code that was written not using std::
>> data structures (or some other gdb specific type) would need a comment
>> explaining why, if nothing else to stop someone replacing the code
>> with std:: types a few months down the line.
>>
> 
> Right, good point.
> I can add a comment here, so that will not happen:
> 
> index 46f985a..4f0d536 100644
> --- a/gdb/buildsym.c
> +++ b/gdb/buildsym.c
> @@ -736,6 +736,10 @@ struct blockvector *
>  void
>  buildsym_compunit::record_inline_range_end (CORE_ADDR end)
>  {
> +  /* The performance of this function is very important,
> +     it shall be O(n*log(n)) therefore we do not use std::vector
> +     here since some compilers, e.g. visual studio, do not
> +     guarantee that for vector::push_back.  */
>    if (m_inline_end_vector == nullptr)
>      {
>        m_inline_end_vector_length = INITIAL_LINE_VECTOR_LENGTH;
> 
> 
> Does that look good (also from the english)?
> 

Hi Andrew,

how are you doing?

are you ok?


Bernd.