This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

C51 libs: Where is ?C?LSTKXDATA and friends documented?

I am trying to  understand some disassembled code, and encounter instances of ?C?LSTKXDATA. Apparently, that function expects 4 bytes of data following the call instruction. And thus must adjust the stack accordingly before RETurn.

https://github.com/NationalSecurityAgency/ghidra/issues/1177

I've seen the arm.com doc page that comes up when searching for this function: http://www.keil.com/support/docs/1964.htm   But that page describes passing arguments only in registers.

Looking at the disassembly, ti does indeed look like ?C?LSTKXDATA starts by popping the return address into DPTR, and then using that pointer to access data, and then uses the incremented address to JMP "return".

But it would be nice to see actual docs on what ?C?LSTKXDATA does, how to call it, and others in that family of functions that have similar call conventions.

Thanks.

Parents
  • I now see that on the page I referenced, I had missed the details for "STK".  But that is still very incomplete.

    For LSTKXDATA we have:

    L = "indicates a long passed in R4, 5, 6, 7" -- but doesn't say the purpose of this long.

    STK = "indicates writing of constant data encoded as DB statements immediately following the library function call." -- that's a grammatical mess. But maybe it means that the function will perform a write operation, after first READing data from the DB statements immediately following the call. (I know it's not writing to those DB locations, because this is code in ROM.)  OK, but how many bytes (DB statements)?

    XDATA = "The memory type field indicates that memory area that is accessed"

    So we infer that the LSTKXDATA function will get some bytes from DBs directly after the call site, and it's going access XDATA, presumably a write operation, for which it will need an address, so that's probably the long passed in R4..R7. Though that last part isn't certain, because, for example, the P type field description explicitly states its a pointer, whereas "L" does not.

    And finally, nowhere does it say how many DB bytes this function can use. Is it fixed at 4? Or is there some means (or part of R4..R7) that indicates a byte count? (I'm pretty sure it's fixed at 4 bytes.)

    So I'm not dissuaded from my assessment that this doc page is too vague to be adequate.

Reply
  • I now see that on the page I referenced, I had missed the details for "STK".  But that is still very incomplete.

    For LSTKXDATA we have:

    L = "indicates a long passed in R4, 5, 6, 7" -- but doesn't say the purpose of this long.

    STK = "indicates writing of constant data encoded as DB statements immediately following the library function call." -- that's a grammatical mess. But maybe it means that the function will perform a write operation, after first READing data from the DB statements immediately following the call. (I know it's not writing to those DB locations, because this is code in ROM.)  OK, but how many bytes (DB statements)?

    XDATA = "The memory type field indicates that memory area that is accessed"

    So we infer that the LSTKXDATA function will get some bytes from DBs directly after the call site, and it's going access XDATA, presumably a write operation, for which it will need an address, so that's probably the long passed in R4..R7. Though that last part isn't certain, because, for example, the P type field description explicitly states its a pointer, whereas "L" does not.

    And finally, nowhere does it say how many DB bytes this function can use. Is it fixed at 4? Or is there some means (or part of R4..R7) that indicates a byte count? (I'm pretty sure it's fixed at 4 bytes.)

    So I'm not dissuaded from my assessment that this doc page is too vague to be adequate.

Children
No data