### Author:  [@mh](https://talk.remobjects.com/u/mh)
#### Post date: [August 24, 2023, 11:14am UTC](https://talk.remobjects.com/t/broken-ptr-syntax/25611/26 "2023-08-24T11:14:25Z")
> [@sollapse](#):
>
> Great, also I’m genuinely amazed by the flexibility this toolchain can offer.
thanx! I am happy to hear that! Please spurred the word ;).
> [@sollapse](#):
>
> |Error||(MSB4181) The MSBuildTask task returned false but did not log an error.|ConsoleApplication1|C:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\RemObjects Software\Elements\RemObjects.Elements.Island.Windows.targets|53||
Reproduced. looks like this crashes LLVM, and the error is not properly reported back. in the full log I see
```auto
-> Phase Generating Output started.
LLVM ERROR: Invalid $ operand number in inline asm string: '
movl $749, %eax
=================================================================
```
I’ll log an issue for passing these errors back more cleanly, if possible.
I have no idea if the error is _valid_, I’d have to check with my colleague @ck.
bugs://E26719
---
### Author:  [@sollapse](https://talk.remobjects.com/u/sollapse)
#### Post date: [August 24, 2023, 1:48pm UTC](https://talk.remobjects.com/t/broken-ptr-syntax/25611/27 "2023-08-24T13:48:19Z")
I was able to compile it by adding an additional $. Likely it confused the parser.
```auto
Module Program
Function testAsm() As Integer
End Function
Sub Main(args as String())
writeLn($"Test: {testAsm()}")
End Sub
End Module
```
---
### Author:  [@ck](https://talk.remobjects.com/u/ck)
#### Post date: [August 24, 2023, 6:16pm UTC](https://talk.remobjects.com/t/broken-ptr-syntax/25611/28 "2023-08-24T18:16:09Z")
That sounds more correct yes. This should match the clang behavior.
---
### Author:  [@sollapse](https://talk.remobjects.com/u/sollapse)
#### Post date: [August 24, 2023, 9:36pm UTC](https://talk.remobjects.com/t/broken-ptr-syntax/25611/29 "2023-08-24T21:36:44Z")
Also, while reviewing a couple of old posts here regarding InlineAsm, has there ever been a decision to allow the use of clobbering and I/O variables? Full assembly should work fine for most needs and as a workaround I can define a variable as static to use it directly.
---
### Author:  [@mh](https://talk.remobjects.com/u/mh)
#### Post date: [August 25, 2023, 11:00am UTC](https://talk.remobjects.com/t/broken-ptr-syntax/25611/31 "2023-08-25T11:00:43Z")
> [@sollapse](#):
>
> Also, while reviewing a couple of old posts here regarding InlineAsm, has there ever been a decision to allow the use of clobbering and I/O variables? Full assembly should work fine for most needs and as a workaround I can define a variable as static to use it directly.
@ck?
---
### Author:  [@sollapse](https://talk.remobjects.com/u/sollapse)
#### Post date: [August 25, 2023, 9:37pm UTC](https://talk.remobjects.com/t/broken-ptr-syntax/25611/32 "2023-08-25T21:37:30Z")
I reviewed the source of the Island RTL, along with reading the VoidAsm documentation. It seems that you do support it, however I’m not sure of the correct syntax of a constraint string for Clang as it’s hard to find clear documentation for this form, just the Extended Asm form for GCC. I’ve tried the following, but the variables still seem not to pass:
```auto
Function testAsm(x As Integer, y As Integer) As Integer
Dim c As Integer
InternalCalls.VoidAsm(" mov $1, %eax
add $2, %eax
mov %eax, $0
","=r,r,r,~{eax}",False,False, c, x, y) '~{} means clobbered register?
Return c
End Function
```
**EDIT** : I found the LLVM IR document which mentions the constraint syntax. However, I’m still noticing the constraints seemingly have no affect in passing the variables to assembly from the argument array.
---
### Author:  [@sollapse](https://talk.remobjects.com/u/sollapse)
#### Post date: [August 28, 2023, 1:28pm UTC](https://talk.remobjects.com/t/broken-ptr-syntax/25611/33 "2023-08-28T13:28:47Z")
Porting the above code to Oxygene also fails. Even when substituting Integer with NativeInt and using the 64bit registers instead. I’m using [https://github.com/remobjects/IslandRTL/blob/master/Source/WindowsHelpers.pas](https://github.com/remobjects/IslandRTL/blob/master/Source/WindowsHelpers.pas) as a guide as well.
---
### Author:  [@mh](https://talk.remobjects.com/u/mh)
#### Post date: [August 28, 2023, 1:36pm UTC](https://talk.remobjects.com/t/broken-ptr-syntax/25611/34 "2023-08-28T13:36:23Z")
> [@sollapse](#):
>
> Porting the above code to Oxygene also fails.
I would have no expectation that this would not behave the same on Mercury and Oxygene, yes.
---
### Author:  [@sollapse](https://talk.remobjects.com/u/sollapse)
#### Post date: [August 28, 2023, 1:46pm UTC](https://talk.remobjects.com/t/broken-ptr-syntax/25611/35 "2023-08-28T13:46:37Z")
Also when testing the workaround method with static variables, under Linux the code runs fine in debug mode. Yet when it’s compiled as release, a segfault occurs:
**Code:**
```auto
Module Program
/**/
Function testAsm(x As Integer, y As Integer) As Integer
Static a, b, c As Integer = 0
a = x : b = y
InternalCalls.VoidAsm("
movl f_t1d_ConsoleApplication3_d_Program.a$$3(%rip), %eax
movl f_t1d_ConsoleApplication3_d_Program.b$$4(%rip), %ebx
addl %ebx, %eax
movl %eax, f_t1d_ConsoleApplication3_d_Program.c$$5(%rip)
","",False,False)
Return c
End Function
Sub Main(args as String())
writeLn($"Test: {testAsm(271, 332)}")
End Sub
End Module
```
**GDB Info from release build:**
Program received signal SIGSEGV, Segmentation fault.
0x00000000002bb852 in GC\_find\_limit\_with\_bound ()
(gdb) backtrace
#0 0x00000000002bb852 in GC\_find\_limit\_with\_bound ()
#1 0x00000000002bb626 in GC\_init\_linux\_data\_start ()
#2 0x00000000002b3336 in GC\_init ()
#3 0x00000000002b230d in ms\_ta\_\_1sBoehmGC6\_LoadGC ()
#4 0x00000000002b270f in ms\_ta\_\_1sBoehmGC3\_Newnp\_vni () at boehmgc.pas:379
#5 0x000000000038e022 in \_\_elements\_entry\_point\_helper () at posixhelpers.pas:603
#6 0x00007ffff7c5b0b3 in \_\_libc\_start\_main (main=0x38df60 \<\_\_elements\_entry\_point\_helper\>, argc=1,
argv=0x7fffffffdfa8, init=, fini=, rtld\_fini=,
stack\_end=0x7fffffffdf98) at …/csu/libc-start.c:308
#7 0x00000000002dcb29 in \_start () at posixhelpers.pas:134
---
### Author:  [@ck](https://talk.remobjects.com/u/ck)
#### Post date: [August 28, 2023, 7:15pm UTC](https://talk.remobjects.com/t/broken-ptr-syntax/25611/37 "2023-08-28T19:15:06Z")
You can continue or ignore that signal. It’s as designed and caught by the GC itself.
---
### Author:  [@sollapse](https://talk.remobjects.com/u/sollapse)
#### Post date: [August 28, 2023, 7:56pm UTC](https://talk.remobjects.com/t/broken-ptr-syntax/25611/38 "2023-08-28T19:56:08Z")
Ok, is there a way to trap the GC segfault in code to bypass the error message? As stated the addition returns normally when compiled with debug symbols. Windows is normal in either debug or release mode. I would prefer to use constraints, however the variables do not seem to pass.
---
### Author:  [@ck](https://talk.remobjects.com/u/ck)
#### Post date: [August 29, 2023, 6:31pm UTC](https://talk.remobjects.com/t/broken-ptr-syntax/25611/39 "2023-08-29T18:31:07Z")
Use this in GDB:
```auto
handle SIGSEGV nostop noprint
```
---
### Author:  [@sollapse](https://talk.remobjects.com/u/sollapse)
#### Post date: [August 29, 2023, 6:50pm UTC](https://talk.remobjects.com/t/broken-ptr-syntax/25611/40 "2023-08-29T18:50:11Z")
Okay, but the problem is that this code is compiled for release so it will not be ran using GDB. It seg faults on execution only as a release binary.
---
### Author:  [@ck](https://talk.remobjects.com/u/ck)
#### Post date: [August 29, 2023, 7:04pm UTC](https://talk.remobjects.com/t/broken-ptr-syntax/25611/41 "2023-08-29T19:04:13Z")
Right but this callstack:
```auto
Program received signal SIGSEGV, Segmentation fault.
0x00000000002bb852 in GC_find_limit_with_bound ()
(gdb) backtrace
#0 0x00000000002bb852 in GC_find_limit_with_bound ()
#1 0x00000000002bb626 in GC_init_linux_data_start ()
#2 0x00000000002b3336 in GC_init ()
#3 0x00000000002b230d in ms_ta__1sBoehmGC6_LoadGC ()
#4 0x00000000002b270f in ms_ta__1sBoehmGC3_Newnp_vni () at boehmgc.pas:379
#5 0x000000000038e022 in __elements_entry_point_helper () at posixhelpers.pas:603
#6 0x00007ffff7c5b0b3 in __libc_start_main (main=0x38df60 <__elements_entry_point_helper>, argc=1,
argv=0x7fffffffdfa8, init=, fini=, rtld_fini=,
stack_end=0x7fffffffdf98) at …/csu/libc-start.c:308
#7 0x00000000002dcb29 in _start () at posixhelpers.pas:134
```
Should be caught by the GC. It’s probably not your release crash…
---
### Author:  [@sollapse](https://talk.remobjects.com/u/sollapse)
#### Post date: [August 29, 2023, 7:11pm UTC](https://talk.remobjects.com/t/broken-ptr-syntax/25611/42 "2023-08-29T19:11:53Z")
I confirmed that it is the release build. I’ve included a link to both the debug and release binaries.
> **[ConsoleApplication3\_binaries.zip](https://wetransfer.com/downloads/b4a42dec0b87de4294c33b06bf227bd420230829191052/876ff0)**
>
> 1 file sent via WeTransfer, the simplest way to send your files around the world
---
### Author:  [@mh](https://talk.remobjects.com/u/mh)
#### Post date: [August 29, 2023, 7:43pm UTC](https://talk.remobjects.com/t/broken-ptr-syntax/25611/43 "2023-08-29T19:43:18Z")
> [@sollapse](#):
>
> I confirmed that it is the release build. I’ve included a link to both the debug and release binaries.
But does this error actually crash the app, when _not_ running in the debugger?
[Previous page](https://talk.remobjects.com/t/broken-ptr-syntax/25611.md?page=1)
[Next page](https://talk.remobjects.com/t/broken-ptr-syntax/25611.md?page=3)