How to mark structure field / variable as volatile?

[xyzz]

I have a function which, simplified, is as follows:

void func(emmc_t *emmc) {
  // some stuff
  emmc->reg->INT_STATUS = 1;
  while (emmc->reg->INT_STATUS) {}
  // more stuff
}

However, Ghidra doesn't know that INT_STATUS can change externally and instead decompiles it to an infinite loop (and kills everything after it). Is there a way to mark a structure field as volatile so that the reads don't get optimized away?

[MulleDK19]

I think you either have to mark the entire region as volatile in the memory map (Windows > Memory Map), or untick "Eliminate unreachable code" (Right click in the decompiler text > Properties > Decompiler > Analysis). I think you can also change whatever type INT_STATUS is, to volatile.

[xyzz]

Marking all memory regions as volatile doesn't change the output at all; unticking "Eliminate unreachable code" does make it a little better, but it still generates loops that look like do {} while (true). If I try to add a "volatile" keyword to a type, like volatile ushort, it just says it's "unrecognized data type".

[cbuschardt]

I can confirm that "Eliminate unreachable code" had no effect.

Similarly, marking the entire region as volatile hamstrings the decompiler. Ideally, volatile could be included as part of the type.

[jeremyherbert]

This problem is common in embedded applications (ie non-os) like on the AVR and ARM Cortex M architecture. An example which occurs frequently is something like:

ISR(TIMER_OVERFLOW) {
  some_register |= 0x01;
}

int main() {
  ...
  while ((some_register & 0x01) == 0) { // wait for the timer to overflow
    do_some_background_work();
  } 
  ...
}

[Jaguar83]

Found a similar condition in PSX code (MIPS processor):

                             LAB_80056408                                    XREF[1]:     80056420 (j)   
        80056408                 lw         v0,0x0 (a1)=>counter1                            = 
        8005640c                 nop
        80056410                 sw         v0,local_30 (sp)
        80056414                 lw         v1,local_30 (sp)
        80056418                 lw         v0,0x0 (a1)=>counter1                            = 
        8005641c                 nop
        80056420                 bne        v1,v0,LAB_80056408

a1 = counter1 = 1f801110 (Horizontal retrace counter)

The decompiled code is:

  do {
  } while (*ptrCounterHorRetrace != *ptrCounterHorRetrace);

Where ptrCounterHorRetrace = counter1

I believe the code should be more along the lines of:

  int counter1;
  int counter2;
  do {
    counter1 = *ptrCounterHorRetrace;
    counter2 = *ptrCounterHorRetrace;
  } while (counter1 != counter2);

I've got the whole block ("hardware_registers" 1f801000-1f802fff) set to volatile.

[antoniovazquezblanco]

For my particular usecase involving embedded targets that update variables inside interrupts, the solution I've found to work the best is to split the memory map isolating that particular variable and marking that split memory map as volatile. This emulates the support of volatile types the best but is a very tedious process. I would love to see volatile type support.

Is there any reason for this to not be a proposal of improvement?

[antoniovazquezblanco]

After tinkering a little bit more I have found that in the desired memory region one may right-click and then Data > Settings... a dialog appears and you may select volatile in mutability.