Simulation issue

[blacksmithasleep]

Are you able to run any simulations? It mentions permissions, but that is not the issue. In compile.log I see the following:

assertion failed [metadata != nullptr]: request to change permissions for interval that isn't tracked
(VMAllocationTracker.cpp:469 change_permissions)
/tools/Xilinx/Vivado/2022.2/bin/rdiArgs.sh: line 312: 3424 Trace/breakpoint trap "$RDI_PROG" "$@"

[arminsch]

I see the same issue, also when trying to run simulations on a UTM virtual ARM machine using Rosetta (as described here: https://gist.github.com/sohnryang/ca5d2512f7c6e0bab87843dbf1a3708f). And it is also mentioned here: https://gist.github.com/sohnryang/ca5d2512f7c6e0bab87843dbf1a3708f?permalink_comment_id=4430497#gistcomment-4430497

I've tried to find any information about the error message, but even googling for VMAllocationTracker.cpp produces only the result above. No sure what is the origin of this error message.

[arminsch]

BTW, @ichi4096: Thanks a lot for your altruism to share your efforts.

[ichi4096]

Thanks @arminsch :-)

I've only tested Vivado by editing, sythesizing, running implementation, generating bitstream and programming devices because that's all we had to do in our classes for now.

But I'll try to debug this issue, which is also seen when starting vitis_hls; my guess is that it doesn't work because of some Docker or Rosetta related issues, since Vivado works in virtual machines otherwise...

The cpp file says somthing with Allocation and I remember somthing about different malloc implementations when going through the Vivado shell scripts, so I have a starting point of investigation.

[arminsch]

Maybe also giving some hints:

• xar, xcrg, xelab, xsc, xvhdl, xvlog all raise the same exception mentioned above)
• xtclshand xsdb raise a somewhat relate exception

assertion failed [result.value != EEXIST]: VmTracker attempted to allocate existing mapping
(ThreadContextVm.cpp:47 mmap)
/opt/Xilinx/Vivado/2022.2/bin/xtclsh: line 72:  2543 Trace/breakpoint trap   (core dumped) "$RDI_BINROOT"/unwrapped/"$PLATFORM_TMP$RDI_OPT_EXT"/rlwrap -rc "$RDI_BINROOT"/loader -exec tclsh8.5 "${RDI_ARGS[@]}"

[arminsch]

Let me know in case you need someone to discuss. I'm eager to help as this seems to be the last remaining issue that prevents me from changing my Laptop-HW.

[ichi4096]

Well I tried strace and ltrace on the vivado_hls binary (in the unwrapped folder) and both seem to be broken under Rosetta. Maybe debugging with gdb will help...

[blacksmithasleep]

@ichi4096, thanks for the quick feedback! I'm looking it this as well

[ichi4096]

I figured out how to run xtclsh and xsdb: Both scripts open the underlying binary (in unwrapped folder) with a software called rlwrap. Installing it separately with apt and replacing the binary in the unwrapped folder with a symlink to the downloaded version of rlwrap makes these two programs work. It's somehow related to ttys... But it's definetly a Rosetta issue.

[ichi4096]

There are certain debugging tools that work when using UTM instead of Docker, such as strace and to a certain extent gdb. However, gdb hasn't been of much use (I think because of the emulation layer inbetween) and strace generated a massive output (see output.txt).

It seems that xvlog does a lot of mmap and mprotect system calls, which generate lots of segfaults. What's interesting is that the last segfault (the one which crashes the program) is a SEGV_MAPPERR and the rest are SEGV_ACCERR... But I have no idea why that's the case. My theory is that the program (ab)uses a specific memory layout that is present in x64 processors but not Arm, and Rosetta somehow doesn't manage to translate it correctly.

I'm unsure if I can go further this route since my knowledge of these things is quite limited and Apple doesn't publicly disclose much of Rosetta's technicalities. My hope is that some shared library Vivado ships with is the culprit and can be replaced with a more recent version and that'll fix the problem.

[blacksmithasleep]

I see. I tried to debug this a bit but no luck on my side as well. I does seem like a Rosetta-related issue. Quite a few people are getting problems when doing mamps: docker/roadmap#384

[ichi4096]

Sorry for the delay, I had some studying to do. The good news: I finally figured out how to debug programs using the RosettaLinux rosetta binary with which x64 ELF binaries are run (using UTM, not Docker).

When running it without arguments, it shows this:

debian@debian:/home/user/Xilinx/Vivado/2022.2/bin/unwrapped/lnx64.o$ /media/rosetta/rosetta 
Usage: rosetta <x86_64 ELF to run>

Optional environment variables:
ROSETTA_DEBUGSERVER_PORT    wait for a debugger connection on given port

version: Rosetta-289.7

Googling the name of the environment variable led to this blog, which explained the whole process.

And instead of getting meaningless translated garbage, with which I can do pretty much nothing since it's JIT-compiled, I get actual x64 assembly :O As was to be expected, there are no debug symbols, but I'll see how far I get.

[ichi4096]

There is very little I can do without debug symbols... So I asked for them here. Probably, I won't get an answer, however, I can ask specifically for the source code of the rlwrap binary since it's GPL licensed. If I can reproduce the error with the source code, maybe I'll get closer to the issue...

[ichi4096]

So… I got a response on the Xilinx support forum, but it doesn‘t help. This issue seems to be specifically rosetta-related, so I reported this issue via the Feedback app in macOS.

In the meantime, somewhere in the EULA, they mention the version of rlwrap they used, which I downloaded via the wayback machine. I‘ll try to compile it with debug symbols and debug it properly.

Also sorry for not updating for a long time, I had some catching up to do with my studies.