Fix bug in scratch_reserve

[fk-sc]

No description provided.

[fk-sc]

@JanMatCodasip, @MarekVCodasip, could you take a look? This change is required to make this Spike MR pass the testing

[fk-sc]

Failure example: gdbserver.py targets/RISC-V/spike32.py DebugChangeString for target with datasize greater than 2

[fk-sc]

There's a logic error in the comparisons in scratch_reserve(). The conditions are backwards - they check if the required space is greater than or equal to the available space, when they should check if it fits within the available space.

If riscv_xlen == 32 then fpr_read_progbuf calls internal_register_read64_progbuf_scratch function that calls scratch_reserve. And here we have our comparisons:

Current code (wrong):

// Option 1: data registers
if ((size_bytes + scratch->hart_address - info->dataaddr + 3) / 4 >=
		info->datasize) {
    // use data registers
}

// Option 2: progbuf  
if ((info->progbuf_writable == YNM_YES) &&
		((size_bytes + scratch->hart_address - info->progbuf_address + 3) / 4 >=
		info->progbufsize)) {
    // use progbuf
}

What happens:

• With datasize=8 condition is false, so it skips using data registers even though there's plenty of space
• With datasize=2 condition is true, so it uses data registers

The conditions should use <= instead of >=:

// Option 1: data registers
if ((size_bytes + scratch->hart_address - info->dataaddr + 3) / 4 <=
		info->datasize) {
    // fine for datasize > 2
}

// Option 2: progbuf  
if ((info->progbuf_writable == YNM_YES) &&
		((size_bytes + scratch->hart_address - info->progbuf_address + 3) / 4 <=
		info->progbufsize)) {
    // fine for larger progbuf
}

[TommyMurphyTM1234]

The conditions should use <= instead of >=:

Was this issue (or at least part of it?) introduced in this PR?

• Fix: Take into account progbuf writability. #424

which includes this change:

	if ((info->progbuf_writable == YNM_YES) &&
			((size_bytes + scratch->hart_address - info->progbuf_address + 3) / 4 >=
			info->progbufsize)) {

[fk-sc]

@TommyMurphyTM1234, the bug was already there; #424 didn’t introduce it, it preserved the same >= check