Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-devel / 2021-02

Apple M1 processor

7 messages · 2 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

C Western

I have been trying out compiling my main application for the new Apple M1 machines, and have two queries:

The traceback on crashes does not include line numbers, when the same flags on other architectures does. Is this something that is easy to fix? Any pointers as to how?

Related to this I am trying to compile the rtl with debug information on by passing DEBUG=1 to the make install when compiling from the current SVN version, but it fails with:

...

/bin/mv -f aarch64/bin/aarch64-darwin/pp ppca64
/Applications/Xcode.app/Contents/Developer/usr/bin/make echotime Start now 21:01:40
/usr/bin/diff ppc3 ppca64
Binary files ppc3 and ppca64 differ

I think a similar issue happens with other architectures on macs, and there I think it was possible to fix by adjusting the starting compiler, but I haven't been able to find a combination that works - any ideas?

My application works fine single threaded, but crashes occasionally when multi threaded, with what I think is some sort of memory corruption, but I haven't been able to pin this down yet, and fixing the above two points would help.

Colin

Reply by email

Jonas Maebe
to C Western
C Western wrote 6 lines
I have been trying out compiling my main application for the new Apple M1 machines, and have two queries: The traceback on crashes does not include line numbers, when the same flags on other architectures does. Is this something that is easy to fix? Any pointers as to how?

It's because no one has implemented Dwarf support in the lineinfo unit yet in for Darwin: https://bugs.freepascal.org/view.php?id=32775

Show quoted text 15 lines
Related to this I am trying to compile the rtl with debug information on by passing DEBUG=1 to the make install when compiling from the current SVN version, but it fails with: ... /bin/mv -f aarch64/bin/aarch64-darwin/pp ppca64 /Applications/Xcode.app/Contents/Developer/usr/bin/make echotime Start now 21:01:40 /usr/bin/diff ppc3 ppca64 Binary files ppc3 and ppca64 differ I think a similar issue happens with other architectures on macs, and there I think it was possible to fix by adjusting the starting compiler, but I haven't been able to find a combination that works - any ideas?

I'll have a look.

Jonas

Reply by email

Jonas Maebe
to Jonas Maebe
Jonas Maebe wrote 18 lines
On 02/02/2021 16:48, C Western via fpc-devel wrote: > Related to this I am trying to compile the rtl with debug information on > by passing DEBUG=1 to the make install when compiling from the current > SVN version, but it fails with: > > ... > > /bin/mv -f aarch64/bin/aarch64-darwin/pp ppca64 > /Applications/Xcode.app/Contents/Developer/usr/bin/make echotime > Start now 21:01:40 > /usr/bin/diff ppc3 ppca64 > Binary files ppc3 and ppca64 differ > > I think a similar issue happens with other architectures on macs, and > there I think it was possible to fix by adjusting the starting compiler, > but I haven't been able to find a combination that works - any ideas? I'll have a look.

Fixed in r48518

Jonas

Reply by email

Jonas Maebe
to C Western: I have been trying out compiling my main application for the new Apple M1 machines, and…
C Western wrote 5 lines
My application works fine single threaded, but crashes occasionally when multi threaded, with what I think is some sort of memory corruption, but I haven't been able to pin this down yet, and fixing the above two points would help.

It's probably a data race. AArch64's memory model is much more relaxed than that of x86-64, so data races are much more likely to lead to errors. Additionally, while on x86 interlocked* routines implicitly act as memory barriers between them (due to an architectural idiosyncrasy), they don't on any other architecture.

Jonas

Reply by email

C Western
to Jonas Maebe: Fixed in r48518 Jonas
Jonas Maebe wrote 21 lines
On 03/02/2021 11:58, Jonas Maebe via fpc-devel wrote: > On 02/02/2021 16:48, C Western via fpc-devel wrote: >> Related to this I am trying to compile the rtl with debug information on >> by passing DEBUG=1 to the make install when compiling from the current >> SVN version, but it fails with: >> >> ... >> >> /bin/mv -f aarch64/bin/aarch64-darwin/pp ppca64 >> /Applications/Xcode.app/Contents/Developer/usr/bin/make echotime >> Start now 21:01:40 >> /usr/bin/diff ppc3 ppca64 >> Binary files ppc3 and ppca64 differ >> >> I think a similar issue happens with other architectures on macs, and >> there I think it was possible to fix by adjusting the starting compiler, >> but I haven't been able to find a combination that works - any ideas? > I'll have a look. Fixed in r48518

Thank you - I can confirm it compiles with the fix for me. I suspect that will be easier to fix than the multi-thread code.

Colin

Reply by email

C Western
to Jonas Maebe: It's probably a data race. AArch64's memory model is much more relaxed than that of…
Jonas Maebe wrote 11 lines
On 02/02/2021 16:48, C Western via fpc-devel wrote: > My application works fine single threaded, but crashes occasionally when > multi threaded, with what I think is some sort of memory corruption, but > I haven't been able to pin this down yet, and fixing the above two > points would help. It's probably a data race. AArch64's memory model is much more relaxed than that of x86-64, so data races are much more likely to lead to errors. Additionally, while on x86 interlocked* routines implicitly act as memory barriers between them (due to an architectural idiosyncrasy), they don't on any other architecture.

I have located a possible fix; however I don't understand why I need to make the change I did. The variable reads/writes of concern currently use SetEvent in one thread and WaitFor in another - do these  not have implicit  memory barriers in them? Or is an explicit memory barrier required in AArch64? (or it could also be a different issue).

Colin

Reply by email

Jonas Maebe
to C Western
C Western wrote 6 lines
I have located a possible fix; however I don't understand why I need to make the change I did. The variable reads/writes of concern currently use SetEvent in one thread and WaitFor in another - do these  not have implicit  memory barriers in them? Or is an explicit memory barrier required in AArch64? (or it could also be a different issue).

Thread synchronisation primitives like SetEvent/WaitFor indeed also serve as memory barriers, so no extra barriers are required.

Jonas

Reply by email