HLIL and dead stack stores

[yrp604]

I have a function which sets up a stack frame for an eret:

setup_el0_return_frame@3b44:
00003b44  e00700a9   stp     x0, x1, [sp {arg_0} {arg_8}]
00003b48  e20f01a9   stp     x2, x3, [sp, #0x10 {arg_10} {arg_18}]
00003b4c  e41702a9   stp     x4, x5, [sp, #0x20 {arg_20} {arg_28}]
00003b50  e61f03a9   stp     x6, x7, [sp, #0x30 {arg_30} {arg_38}]
00003b54  e82704a9   stp     x8, x9, [sp, #0x40 {arg_40} {arg_48}]
00003b58  ea2f05a9   stp     x10, x11, [sp, #0x50 {arg_50} {arg_58}]
00003b5c  ec3706a9   stp     x12, x13, [sp, #0x60 {arg_60} {arg_68}]
00003b60  ee3f07a9   stp     x14, x15, [sp, #0x70 {arg_70} {arg_78}]
00003b64  f04708a9   stp     x16, x17, [sp, #0x80 {arg_80} {arg_88}]
00003b68  f24f09a9   stp     x18, x19, [sp, #0x90 {arg_90} {arg_98}]
00003b6c  f4570aa9   stp     x20, x21, [sp, #0xa0 {arg_a0} {arg_a8}]
00003b70  f65f0ba9   stp     x22, x23, [sp, #0xb0 {arg_b0} {arg_b8}]
00003b74  f8670ca9   stp     x24, x25, [sp, #0xc0 {arg_c0} {arg_c8}]
00003b78  fa6f0da9   stp     x26, x27, [sp, #0xd0 {arg_d0} {arg_d8}]
00003b7c  fc770ea9   stp     x28, x29, [sp, #0xe0 {arg_e0} {arg_e8}]
00003b80  124138d5   mrs     x18, sp_el0
00003b84  f27f00f9   str     x18, [sp, #0xf8 {arg_f8}]
00003b88  c0035fd6   ret     

This turns into reasonable LLIL/MLIL:

setup_el0_return_frame@3b44:
   0 @ 00003b44  int64_t arg_0 = x0
   1 @ 00003b44  int64_t arg_8 = x1
   2 @ 00003b48  int64_t arg_10 = x2
   3 @ 00003b48  int64_t arg_18 = x3
   4 @ 00003b4c  int64_t arg_20 = x4
   5 @ 00003b4c  int64_t arg_28 = x5
   6 @ 00003b50  int64_t arg_30 = x6
   7 @ 00003b50  int64_t arg_38 = x7
   8 @ 00003b54  int64_t arg_40 = x8
   9 @ 00003b54  int64_t arg_48 = x9
  10 @ 00003b58  int64_t arg_50 = x10
  11 @ 00003b58  int64_t arg_58 = x11
  12 @ 00003b5c  int64_t arg_60 = x12
  13 @ 00003b5c  int64_t arg_68 = x13
  14 @ 00003b60  int64_t arg_70 = x14
  15 @ 00003b60  int64_t arg_78 = x15
  16 @ 00003b64  int64_t arg_80 = x16
  17 @ 00003b64  int64_t arg_88 = x17
  18 @ 00003b68  int64_t arg_90 = x18
  19 @ 00003b68  int64_t arg_98 = x19
  20 @ 00003b6c  int64_t arg_a0 = x20
  21 @ 00003b6c  int64_t arg_a8 = x21
  22 @ 00003b70  int64_t arg_b0 = x22
  23 @ 00003b70  int64_t arg_b8 = x23
  24 @ 00003b74  int64_t arg_c0 = x24
  25 @ 00003b74  int64_t arg_c8 = x25
  26 @ 00003b78  int64_t arg_d0 = x26
  27 @ 00003b78  int64_t arg_d8 = x27
  28 @ 00003b7c  int64_t arg_e0 = x28
  29 @ 00003b7c  int64_t arg_e8 = x29
  30 @ 00003b80  x18_1 = _ReadStatusReg(SP_EL0)
  31 @ 00003b84  uint64_t arg_f8 = x18_1
  32 @ 00003b88  return 

However, the HLIL is not quite as useful:

setup_el0_return_frame@3b44:
   0 @ 00003b80  uint32_t SP_EL0
   1 @ 00003b80  _ReadStatusReg(SP_EL0)
   2 @ 00003b88  return 

This is potentially a dupe/related to #1728.

I think I understand why this happens: the stores aren't used in the function, so they are removed via dead store removal. My generic assumption around HLIL is that it should contain all info that is relevant to understanding what a program is doing -- in this specific case for example the fact that the structure lives on the stack is not relevant to HLIL, but a structure being populated is. I'm unsure what, if anything, should change about this and I can think of a few options that might help solve this problem:

1. Should I change the calling convention of the function and have it pass in a pointer to a frame structure that lives in the calling function which this function would populate? Alternatively have it return a stack allocated function containing the frame?
2. Should HLIL display a warning in the that says something along the lines of "you likely want to look at this function at a lower level il, because something weird is happening", potentially with more info?
3. Should HLIL to not eliminate dead store stores outside the current stack frame?
4. Lift eret and define the stack variables as an input to the instruction which might help dataflow determine that these stores arent dead, eventually?
5. Something else I haven't considered?

[withzombies]

That function doesn't tear down a stack frame. I don't think those stores should be marked as dead.

[plafosse]

My preferred option would be if we were to somehow detect conditions where HLIL isn't going to make much sense (e.g. things that are hand rolled assembly) and show a lower level of IL. As of right now we don't have a good idea on what that kind of detection would look like. Unfortunately I don't think we'll have a great solution here for some time yet. There are some things that we could do to help with errant elimination of dead stack stores.

[yrp604]

Dead store elimination visualization fixes this! Thanks all.