From: cross@spitfire.i.gajendra.net   
      
   In article <5ad13902-cf39-4e2c-9151-a1583abc8b3cn@googlegroups.com>,   
   muta...@gmail.com  wrote:   
   >Thanks Dan.   
   >   
   >I posted that at something like 1am hoping for an answer when   
   >I woke up, but there wasn't one so I went ahead and did my own   
   >version (below), which took so long, including interruptions, that   
   >by the time I came to post it I found your message. :-)   
   >   
   >I'll just answer some points you raised.   
   >   
   >On Sunday, April 2, 2023 at 9:37:28 AM UTC+8, Dan Cross wrote:   
   >   
   >> >And the value would have been corrupt anyway because of this:   
   >> >   
   >> > movb _buf.8+3(%edx), %dl   
   >   
   >> What do you mean, "corrupt?" `%edx` holds an offset into some   
   >> buffer at the beginning of this instruction; that offset is not   
   >> used after this instruction, so the compiler chose to load a   
   >> byte into the register. That byte is eventually OR'd into the   
   >> "cluster" value in `%ebx`.   
   >   
   >Yes, I can't remember why I was confused.   
   >   
   >Note that adding printf (which means edx may be trashed)   
   >causes different code to be generated (to avoid edx being   
   >trashed), and I may have remembered that or something.   
   >   
   >> Deallocate the stack space allocated above. Note: it would look   
   >> like both `%ebx` and `%edi` could be clobbered here, but I'm   
   >> guessing you're using the "cdecl" calling convention, where   
   >> `%ebi` is callee-save.   
   >   
   >Not sure if ebi means ebx or edi, but both are preserved by   
   >the called function I think (edi apparently only in 32-bit code):   
      
   `%ebi` was a typo, but it doesn't matter, as the ABI (that you   
   appear to be using) says both will be preserved.   
      
   >> The code appears to be correct given the source code.   
   >   
   >Yep, thanks.   
   >   
   >Since I can't add printf at will without making the problem   
   >go away I will insert a call to __brkpoint() into the generated   
   >assembler to see if that enables me to track the problem down.   
      
   It's not clear what problem you are referring to.  You asked   
   whether there was a compiler bug, but it appears there is not;   
   at least not in this case.   
      
   Generally, it would help if you stated what the actual problem   
   you need assistance with is.   
      
   Instead of adding a call to a builtin function, perhaps   
   consider inserting an `int3` instruction.   
      
   >[snip]   
   >	andl	$-16, %edx  ; only want low 4 bits of dl   
   >        ; buf[offset + 3] = buf[offset + 3] & 0xf0;   
      
   No.  This _clears_ the low bits of `%edx`: -16 in two's   
   complement is 0xFFFFFF00.  The assignment is done later.   
   What this code says is that you only want the _high_ bits   
   of `%edx`.   
      
   >[snip]   
   >	movb	%dl, _buf.8+3(%ecx)   ; those low 4 bits now available for insert   
      
   _high_ bits.   
      
   	- Dan C.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)