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-boun...@lists.freepascal.org> on behalf
of Michael Ring via fpc-devel <fpc-devel@lists.freepascal.org>
*Sent:* Tuesday, April 21, 2020 6:09:57 PM
*To:* fpc-devel@lists.freepascal.org <fpc-devel@lists.freepascal.org>
*Cc:* Michael Ring <m...@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@lists.freepascal.org
<mailto:fpc-devel@lists.freepascal.org>
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
