[fpc-devel] Possible error in generated code for arm?

[Michael Ring]

The information you see is coming straight out of the debugger (Segger 
Ozone),

and perhaps I should have said this in the first post,

the pointer that is fed in the Fillchar procedure is complete nonsense, 
it points into the stack area which means im my case that fillchar 
overwrites the stack and at some point writes into non-RAM which crashes 
the cpu.

Value of R0 inside of Fillchar: 20017ef4 (Stack Area at the end of RAM)

Value of R0 on entry: 200000f8 which looks OK as it is close to the 
start of RAM where it got statically allocated:

implementation
var
   xIdleTaskTCB : TStaticTask;
   uxIdleTaskStack : array[0..configMINIMAL_STACK_SIZE-1] of TStackType;
   xTimerTaskTCB : TStaticTask;
   uxTimerTaskStack : array[0..configTIMER_TASK_STACK_DEPTH-1] of 
TStackType;


The only other thing than a compiler bug could be that my Implementation 
of the memset wrapper is wrong, the prototype is:

void * memset ( void * ptr, int value, size_t num );

and both h2pas and me came to the same implementation:

function memset(pxBuffer:pointer; value : uint32; count : Tsize):pointer; cdecl;

You can ignore the fact that I get an uint32 passed in and Fillchar uses 
a byte, only the byte part is relevant:

 From C Documentation of memset:
      void * memset ( void * ptr, int value, size_t num );

         Fill block of memory
         Sets the first /num/ bytes of the block of memory pointed by 
/ptr/ to the specified /value/ (interpreted as an unsigned char).

I have also hacked the code of my memset function in a way that I think 
that it should work:

begin
   asm
     LDR     R0, [R11, #-0x30]
     LDRB    R2, [R11, #-0x34]
     LDR     R1, [R11, #-0x38]
     bl fillchar
   end;
   Result := pxBuffer;
end;

Implemented this way the function works as expected.

Michael

Am 22.04.20 um 01:10 schrieb Alexander Grotewohl:
> Can you run gdb on there? When you break inside memset does the 
> pxBuffer pointer make sense (not 0x0)? Do the other two variables come 
> in correctly?
>
> Do you call memset or does an api in the OS call it? Perhaps it's a 
> pointer to a pointer on accident?
>
> If you are required to provide memset are you also providing other 
> memory functions, for example to allocate? Is it passing a valid 
> pointer back (one that eventually gets to memset)?
>
> Just a bit of a brainstorm.. sorry if I've oversimplified or missed 
> the mark entirely :)
>
> --
> Alexander Grotewohl
> https://dcclost.com
> ------------------------------------------------------------------------
> *From:* fpc-devel <fpc-devel-bounces at lists.freepascal.org> on behalf 
> of Michael Ring via fpc-devel <fpc-devel at lists.freepascal.org>
> *Sent:* Tuesday, April 21, 2020 6:09:57 PM
> *To:* fpc-devel at lists.freepascal.org <fpc-devel at lists.freepascal.org>
> *Cc:* Michael Ring <mail at michael-ring.org>
> *Subject:* [fpc-devel] Possible error in generated code for arm?
>
> I have the following code in a unit (I need to provide a memset 
> function to be able to link to freertos):
>
> function memset(pxBuffer:pointer; value : byte; count : 
> Tsize):pointer; cdecl;
> begin
>   FillChar(pxBuffer,count,value);
>   Result := pxBuffer;
> end;
>
>
> When I look at the assembler code generated by latest Trunk fpc 
> something is very odd @08000970, I'd expect to see
>
> LDR           R0, [R11, #-0x30]
>
> but in fact I see:
>
>  08000970   SUB.W          R0, R11, #0x30
>
> which makes no sense to me and later the code crashes inside of the 
> FillChar routine.
>
> Compiler Bug? Or me overlooking something? I tried to compile with -O- 
> and -O1, with -O2 the generated code is a little different but there 
> the SP is loaded to R0 which I do not understand, I'd expect R0 to be 
> set to address of pxBuffer. (this is for armv7em, for armv6 also looks 
> odd.
>
>
> Thank you for your help,
>
> Michael
>
> FREERTOS_$$_MEMSET$POINTER$BYTE$LONGWORD$$POINTER
> DEBUGSTART_$FREERTOS
> memset
> $Thumb
> begin
>  08000958   MOV            R12, SP
>  0800095A   PUSH.W         {R11, LR}
>  0800095E   SUB.W          R11, R12, #4
>  08000962   SUB            SP, SP, #0x48
>  08000964   STR            R0, [R11, #-0x30]
>  08000968   STRB           R1, [R11, #-0x34]
>  0800096C   STR            R2, [R11, #-0x38]
> FillChar(pxBuffer,count,value);
>  08000970   SUB.W          R0, R11, #0x30
>  08000974   LDRB           R2, [R11, #-0x34]
>  08000978   LDR            R1, [R11, #-0x38]
>  0800097C   BL SYSTEM_$$_FILLCHAR$formal$LONGINT$BYTE  ; 0x080002
> Result := pxBuffer;
>  08000980   LDR            R0, [R11, #-0x30]
>  08000984   STR            R0, [R11, #-0x3C]
>
> Am 21.04.20 um 23:07 schrieb Joao Schuler:
>> just as point for consideration, I'm not sure if data alignment will 
>> improve speed on future processors:
>> https://lemire.me/blog/2012/05/31/data-alignment-for-speed-myth-or-reality/ 
>>
>>
>> Food for thought: imagine if we had single (32 bits floating point) 
>> values dynamic arrays with 1 million values each: a b and c. I would 
>> love to have something like this:
>> a := b + c;
>>
>> _______________________________________________
>> fpc-devel maillist  -fpc-devel at lists.freepascal.org  <mailto:fpc-devel at lists.freepascal.org>
>> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
>
> _______________________________________________
> fpc-devel maillist  -  fpc-devel at lists.freepascal.org
> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20200422/7fae3b7b/attachment.html>