On 6/11/26 4:21 AM, Schimpe, Christina wrote:
>>> It seems that you did not change the code as discussed here:
>>> https://sourceware.org/pipermail/gdb-patches/2026-May/227699.html
>>>
>>> Would you mind sharing the reason for that?
>>> In my opinion this is necessary.
>> I blame the weekend. Leave on friday thinking "I'll do it on monday", arrive
>> on monday thinking "I did it last friday".
>>
>> I made sure to make the change now. Added the asserts that the length is
>> 0 in the move operator, which means we won't need to worry about freeing
>> the memory.
> But isn't it possible that "len > sizeof (u.buf)" or at least "len > 0" at this point ?
Not really. Since we can't have copying of entries, if an actual entry 
was stored in the variable that is receiving a move, we lose information 
on an entry or we forgot to clear the incomplete instruction (which 
means we never added it to the history). The code is built for this to 
be the case, so I am asserting that the length is 0 to catch these 
mistakes and not let execution information be lost.

-- 
Cheers,
Guinevere Larsen
it/its
she/her (deprecated)

>
> So before this code:
>
>>>>> +    addr = other.addr;
>>>>> +    len = other.len;
>>>>> +    memcpy (u.buf, other.u.buf, sizeof (u.buf));
> Christina
> Intel Deutschland GmbH
>
> Registered Address: Dornacher Strasse 1, 85622 Feldkirchen, Germany
> Tel: +49 89 991 430,www.intel.de
> Managing Directors: Harry Demas, Jeffrey Schneiderman, Yin Chong Sorrell
> Chairperson of the Supervisory Board: Nicole Lau
> Registered Seat: Munich
> Commercial Register: Amtsgericht Muenchen HRB 186928