Stack Pointer points to reserved Memory

Question

I am debugging a code for a cryptographic implementation on a Tricore TC275 from Infineon (reference assembly language).

PMI_PSPR (wx!p): org = 0xC0000000, len = 24K  /*Scratch-Pad RAM (PSPR)*/ 
DMI_DSPR (w!xp): org = 0xD0000000, len = 112K  /*Local Data RAM (DSPR)*/

The stack pointer a[10] always points to a reserved memory area after a call to the mac function.

###### typedefs ######
typedef uint16_t limb_t;
typedef limb_t gf_t[DIGITS]; //DIGITS=312
typedef int32_t dslimb_t;
################################

/**Multiply and accumulate c += a*b*/
void mac(gf_t c, const gf_t a, const gf_t b)
1: 0xC0000812:   D9 AA 40 9F   LEA     a10,[a10]-0x9C0 //Load eff. addr.
       /*Reference non-Karatsuba MAC */
       dslimb_t accum[2*DIGITS] = {0};
2: 0xC0000816:   40 A2         MOV.AA  a2,a10
3: 0xC0000818:   D2 02         MOV     e2,0x0 //move 0x0 to d2 and d3
4: 0xC000081A:   C5 03 37 40   LEA     a3,0x137 // 0.5*length of accum
5: 0xC000081E:   89 22 48 01   ST.D    [a2+]0x8,e2 //<= fails here
6: 0xC0000822:   FC 3E         LOOP    a3,0xC000081E 
7: 0xC0000824:   40 AF         MOV.AA  a15,a10

###contents of relevant registers###
                 before        after
1: a[10]         D000 0600     CFFF FC40 (not definend in memory map?)
2: a[2]          D000 0A06     CFFF FC40
3: d[2]          0000 0002     0000 0000
3: d[3]          0000 0000     0000 0000 (would have been set to zero too)
4: a[3]          0000 0186     0000 0137 (#of iterations in loop)
5: a[2]          CFFF FC40     (store failed here)
value@CFFF FC40  ???? ????     ???? ???? (write is not allowed I guess)

0x9C0 = 2496 (base10) and the length of the array accum is 624, each element containing an int32_t. Thus 624*4 = 2496 Bytes get allocated or what?

But at this address in memory, no writes are allowed as far as I understand the memory map which is given to the linker... But the generated assembly code tries to do in line 5?

Does anybody know what I might be doing wrong here? I also tried to use calloc to allocate memory on the heap (instead of the stack like the code above does right?) but the programm still crashed.

I also copied the line dslimb_t accum[2*DIGITS] = {0} to the start of the program where it was executed without an error.

Thank you very much for any help!

EDIT

mac is called like that, uniform samples some uniform random numbers

gf_t sk_expanded[DIM],b,c;
for (unsigned i=0; i<DIM; i++) {
    noise(sk_expanded[i],ctx,i);
}
for (unsigned i=0; i<DIM; i++) {
    noise(c,ctx,i+DIM); //noisy elements in c after call
    for (unsigned j=0; j<DIM; j++) {
        uniform(b,pk,i+DIM*j); //uniform random numbers in b after call
        mac(c,b,sk_expanded[j]); //fails here on first call
    }
    contract(&pk[MATRIX_SEED_BYTES+i*GF_BYTES], c);
}

this code runs on my host machine, but on my tricore microcontroller it fails in the first mac() function call.

_Thus 624*4 = 2496 Bytes get allocated or what?_. Unless compile target is 64bit. then double it. — ryyker, Jul 25 '18 at 11:50
@ the code which actually produces the error, is already between the assembly instr. see `dslimb_t accum[2*DIGITS] = {0};` — jonnyx, Jul 25 '18 at 12:02
If the `a10` is "stack pointer" and it is `0xD0000600` before call, and you want 2496 bytes, then you are out of luck, as there's only 0x600 bytes left (1536 bytes). You have to move that local variable to other part of memory. Usually on such constrained systems one does design whole memory consumption/usage alongside the algorithm and has some kind of memory map, then the C code does less of the common dynamic allocation, which makes the source usually a bit less elegant/clean, but as you have limited resources, sometimes it's better than other hacks. — Ped7g, Jul 25 '18 at 12:27
You can also check, if you can bump up the stack size somewhere in linker script or build options. But fully understanding the memory consumption is still probably a must, as basically if you call two functions with similar request inside, it will fail again, even if separately each of them works. (I think I can actually turn this into answer ... will rethink it and post+delete comments, if it really fits) — Ped7g, Jul 25 '18 at 12:28
@Ped7g thank you sir, i just checked allocating an arroy of size one, that worked! do have an idea why calloc() did not work? my heap should be 4k big... — jonnyx, Jul 25 '18 at 12:42
@jonnyx make some "map" of how the memory chips of your systems are used, track down where the code lands, where is stack, where are data, read-only data, and see yourself, if you are already like filling the system up, or there's enough of unused memory, but the current configuration (linker script + build options) just position you into situation where you run out of resources at runtime. Then redesign your code and build process (linking) to use the available resources more effectively, making your code work (or rewrite your code to require less memory by using more efficient algorithm). — Ped7g, Jul 25 '18 at 13:10

Ped7g · Accepted Answer · 2018-07-25T13:00:30.463

As the "stack pointer" a10 is 0xD0000600 before, and stack grows downward on this platform, and the memory chip assigned to this area starts at 0xD0000000 => you have only 0x600 bytes of stack memory available for locals and other function calls (and their locals!).

Does anybody know what I might be doing wrong here?

But you are trying to allocate 0x9C0 bytes (plus few more for b and c, unless those end in registers, and the optimizer is smart enough to not allocate stack space for them), which leads to going outside of the designed memory area, and first write instruction then will crash. Actually if you would request many more bytes, you can accidentally start inside the Scratch-pad RAM (the resulting address being very close to 0xC0000000), then the code will crash during clearing the array, once it would left the scratch-pad area.

But the generated assembly code tries to do in line 5?

The generated code doesn't check for memory availability in C, related to this kind of problems the C is "unsafe" programming language, and it's responsibility of programmer + maintainer/operator to build the code and run it in such environment where the stack has enough space. Or add checks into code which is so dynamic, that it's not possible to evaluate the stack usage during development and the code should handle full-stack situations gracefully.

I also tried to use calloc to allocate memory on the heap (instead of the stack like the code above does right?) but the programm still crashed.

Seems like different problem, or you have also full heap (from comment "heap should be 4k" - that sounds like very tiny heap, maybe you exhausted it with other dynamic allocations already, also fragmentation may prevent your memory allocator to return continuous valid 3k block for your array). Heap allocators tend to return NULL when their pool is exhausted, but maybe your platform is so limited, that the memory allocator is missing such safety code in implementation, to make it smaller.

I also copied the line dslimb_t accum[2*DIGITS] = {0} to the start of the program where it was executed without an error.

Then it's global variable, which gets placed into the .data-like segment, which is placed into sufficiently big memory area.

And yes, 624 32 bit integers needs at least 2496 (624*4) bytes of memory (in C language you usually pay zero price for abstraction, so in this case any piece of 2496 byte long memory, which is aligned as your platform requires, is enough to make this possible, in other languages like Java the total cost of such array is considerably higher, as there's also GC housekeeping and the array management data, so you can probably count about 3000-3500 bytes needed on such platform).

Usually when one develops on so much constrained system (asking for 3k of stack space for locals sounds as something completely negligible in desktop/web world of programming, but on small embedded systems or old 8/16 bit computers that may be serious amount of memory), it may help to design the code and algorithm in "data driven" way, i.e. you plan your memory usage completely, including where the code resides (and how big it can be), where the local/global variables are, and to be aware what is the maximum stack needed to run through all states of the code.

You can check why the stack is so low in the first place - the "local data RAM" seems to be ~110k big, so maybe you have enough space there, and there's some option during build to resize the stack (or linker script can be adjusted).

Actually you should check your whole memory consumption design, i.e. what data you really need to have in memory, where it is, which are temporary and what are they life cycle, etc (at least at rough kilobytes estimate), and check that against the physically available memory on the chip, so you can get the idea how carelessly you can write the code, or eventually if you are already out of memory for your particular task, even before the start of implementation. (you can start by checking the linker map file, to see how much of the code is produced, and how big are the fixed variables in .data/.bss/.rodata/etc sections, then check all local variables and heap allocations)

Then maybe allocate the required memory in some kind of structs. Do you even need any dynamic allocation? Can't you simply design whole .data segment already in the code as few global struct variables, grouping various data by the abstraction where they belong, and use those globals in the other code, without any dynamic allocation at all?

Also if you are writing some kind of library/support function, make sure you don't exhaust all resources of the platform, otherwise it's not clear how one would use your functionality alongside their real task. :)

thank you for this great explanation! helped me alot! – jonnyx Jul 25 '18 at 13:03 — jonnyx, Jul 25 '18 at 13:03

Stack Pointer points to reserved Memory

1 Answers1