What constraint is not correct with this inline assembly? - c++

Question

I have x86 (32-bit) inline assembly in C++ code being compiled for 32-bit Linux by gcc 9.3.0. At the end of the asm call, I get the error 'asm' has impossible constraints. It doesn't tell me which constraint(s) are "impossible" or why.
I understand the syntax of the __asm__(...) statement as documented here, and I spent some time trying to prove why each constraint is correct, but I can't figure out which constraints to add or remove, or the offending assembly that is violating a constraint.
Here's the code:
extern int view_pitch;
static int scale;
static int rle_remainder;
static int height;
static short *color_table;
static PIXEL *RLE_palette;
static int repeat;
static PIXEL *dest;
static UCHAR *src;
void RLE_blit(void)
{
__asm__ __volatile__ (
" mov %2, %%edi\n"
" push %%ebp\n"
" mov %3, %%edx\n"
"mloop:\n"
" xor %%ecx, %%ecx\n"
" mov (%%edx), %%cl\n"
" add $0x2, %%edx\n"
" imul %4, %%ecx\n"
" add %0, %%ecx\n"
" xor %%eax, %%eax\n"
" mov %%ecx, %%ebx\n"
" and $0xffff, %%ecx\n"
" shr $0x10, %%ebx\n"
" mov %%ecx, %0\n"
" cmp $0x0, %%ebx\n"
" jbe mloop\n"
// color region code
" mov -0x1(%%edx), %%al\n"
" mov %%eax, %%ecx\n" // save orginal pixel in eax
" and $0x1f, %%eax\n" // now modulo original pixel by 32 to get offset
" mov %5, %%esi\n" // pointer to color table
" jz bypass\n"
" shr $0x5, %%ecx\n" // divide pixel by 32 to get region
" mov (%%esi,%%ecx,2), %%cx\n" // get region number from region array into cx
" shl $0x5, %%ecx\n" // multiply by 32 to get start of region
" mov %6, %%esi\n"
" add %%ecx, %%eax\n" // add offset
" mov (%%esi,%%eax,2), %%ax\n"
" cmp %1, %%ebx\n" // is run length <= than remaining column height
" jbe no_run_len_adjust\n" // yes: don't adjust
" mov %1, %%ebx\n" // no : set run length to height
"no_run_len_adjust:\n"
" sub %%ebx, %1\n"
" mov %7, %%ebp\n"
" mov %8, %%esi\n"
"run_len_loop:\n" // BEGIN outer run length loop
" mov %%ebp, %%ecx\n"
"col_loop:\n" // BEGIN inner column repeat loop
" dec %%ecx\n"
" mov %%ax, (%%edi,%%ecx,2)\n"
" jnz col_loop\n" // END column repeat loop
" add %%esi, %%edi\n"
" dec %%ebx\n"
" jnz run_len_loop\n" // END run length loop
" cmp $0x0, %1\n"
" jg mloop\n"
" jmp exit1\n"
"bypass:\n"
" mov %%ebx, %%eax\n"
" imul %8, %%eax\n"
" add %%eax, %%edi\n"
" sub %%ebx, %1\n"
" cmp $0x0, %1\n"
" jg mloop\n"
"exit1:\n"
" pop %%ebp\n"
:"+m"(rle_remainder), "+m"(height)
:"m"(dest), "m"(src), "m"(scale), "m"(color_table), "m"(RLE_palette), "m"(repeat), "m"(view_pitch)
:"esi", "edi", "eax", "ebx", "ecx", "edx", "memory"
);
}
Here's the rundown of why I think what I have is right:
Outputs: rle_remainder and height are both read and written-to, so the +m is appropriate.
Inputs: dest, src, scale, color_table, RLE_palette, repeat and view_pitch appear only to be read from; they aren't in the "destination" position of any instruction. So the m means they're being (only) read from.
The list of clobbered registers ("esi", "edi", "eax", "ebx", "ecx", "edx") contains all registers that are modified. Since some of the modified registers are 8 or 16-bit "parts" of these registers, like ax, these parts of the registers don't need to be explicitly specified, because the whole 32-bit register they're a part of is already being listed as clobbered.
"memory" is listed as clobbered to provide a read/write barrier for memory addresses being written to, not only the memory locations of the outputs themselves. For example, mov %%ax, (%%edi,%%ecx,2) clobbers memory.
I didn't use the goto keyword, because no C labels are being used -- the only labels being jumped to here are labels within this block of inline assembly.
The frame pointer ebp gets modified during the course of the code, but restored at the end, so I didn't list it as clobbered. If I do list it, gcc throws an error, because you're not allowed to tell gcc that you clobbered the frame pointer anymore, I don't think. Either way, the code fails to compile with or without ebp called out as clobbered.
Speculation: Could it be complaining that ebp gets modified at all? Even though we restore the value of it back to the original at the end of the code -- guaranteed -- unless the program crashes? The docs weren't clear on whether the rule is "you can't modify ebp at all, even temporarily" or "if you modify ebp, the value at the end of your inline asm must be restored to the original". If it's the former, then my code is wrong, because ebp gets modified during the execution of this code.
Clearly I am missing something about gcc's expectations of either the constraints or the assembly, but I can't spot what it is.