Is the compiler doing wrong

I have been trying to find out why a list of mine was not listing its elements in the intended order and started adding some logging here and ther to check if it called the correct methods when suddenly it started working. I removed all logging except the last one and it still worked. I commented this last one and it doesn’t work anymore. Here is the C and generated assembler:

static int Compare_Childs(const void* pa, const void* pb)
{
  const KeyInfo* sa = pa;
  const KeyInfo* sb = pb;

//if (sa->Key & FLTreeMode_OrderBy_Queue) Log("Child\n");
  // Compare by object types
  int val = (sa->Key & Key_Mask_Sort) - (sb->Key & Key_Mask_Sort);
  if (val) return val;

  if ((sa->Key & FLTreeMode_Mask_Keys) == Key_FlatTrack)
   return Compare_Flat(pa, pb);

  return Compare_SameChilds(pa, pb);
}

LDR    R2,[R0,#0]
LDR    R12,[R1,#0]
AND    R3,R2,#&1F
AND    R12,R12,#&1F
SUBS   R3,R3,R12
MOVNE  R0,R3
MOVNE  PC,R14
AND    R2,R2,#&FF
CMP    R2,#&FD
BNE    Compare_SameChild
BEQ    Compare_Flat

As far as I can tell the assembler is correct:

• the assembler seems to match the C code
• R0 and R1 are left untouched so are passed correctly to the Compare_Flat/SameChild
• R2 and R3 are modified but then C conventions allow registers R0-R3 to be corrupted on exit of a function.
• R12 is modified too but the its only official use is at function entry (the setup of the stacktrace: MOV R12,R13 → STM R13!, … → SUB R11,R12,#4 ) the rest of the time it can be used freely
• uncommenting the log causes the code to use more register so R4-R5 are then saved on entry & restored on exit so could R4 or R5 be corrupted by the functions calls? No the Compare_xxx functions save those registers too.

I don’t see what’s happening here.

Actually it all depends of the contents of the Log() function.

I reduced it to the minimal code:

static void Log()
{
  char LogBuffer[4];
//    memcpy(LogBuffer, "Log", 3);
  snprintf(LogBuffer, sizeof(LogBuffer), "Log");
}

static int Compare_Childs(const void* pa, const void* pb)
{
  const KeyInfo* sa = pa;
  const KeyInfo* sb = pb;

if (sa->Key & FLTreeMode_OrderBy_Queue) Log();
  // Compare by object types
  int val = (sa->Key & Key_Mask_Sort) - (sb->Key & Key_Mask_Sort);
  if (val) return val;

  if ((sa->Key & FLTreeMode_Mask_Keys) == Key_FlatTrack)
    return Compare_Flat(pa, pb);

  return Compare_SameChilds(pa, pb);
}

It all seems dependant of that snprintf() call. If I replace it by something like the commented memcpy(), the issue reappears. Could it be a issue with SharedCLib? The version here is 5.92 (28 May 2016) .

I think it is because your LogBuffer has a size of 1. With the memcpy you can introduce a stack corruption which might be such that your code starts working.
With the snprintf it only writes 1 character in LogBuffer and does not add a zero after it.

I would suggest to first change the LogBuffer to an array (eg char LogBuffer¹⁰²⁴) and see if this changes things.

No that’s just textile mangling which Andre tried to avoid with his pre tag, Logbuffer is

char LogBuffer[4];

Andre.

Put

bc..<space>some code

at the beginning of your first line of code and

p.<space>some text

at the beginning of the first line of normal text after the code.

I fixed the formatting by putting by putting “pre” tag before “code” tag instead of after.

Anyway Leo’s idea of stack corruption led me to something. Following the path of the Compare_Flat() function I have ChildInfo structures on the stack with lots of “union” substructures filled in correspondence with the type of objects manipulated. It’s a case of an uninitialised info used later when comparing the objects.

And the memcpy is copying three bytes, whereas the snprintf will copy four – including the trailing NULL.
So if you’re accessing LogBuffer later as a string then the memcpy version would go pretty badly wrong.

I was wondering where 4 in

LogBuffer⁴

was comming from.