VMWare shared drive vs Debian Stretch

This note is about problems with VMWare shared drives failing to mount.

My previous setup was VMWare Fusion 8 and Debian 8 (jessie), with the VMWare-recommended open-vm-tools. After upgrading to VMWare Fusion 10 and Debian 9 (stretch), the shared folder (~) on the Mac was no longer visible from Debian (~/mac, a symbolic link to /mnt/hgfs).

After looking here, I added this line to /etc/fstab:

vmhgfs-fuse /mnt/hgfs fuse defaults,allow_other 0 0

but rebooting hung, and invited me to log in as system to fix the problem.

Other posts in the reference stated that you need to mount to /mnt/hgfs/mac: so, edit the /etc/fstab line to

vmhgfs-fuse /mnt/hgfs/mac fuse defaults,allow_other 0 0

and the system rebooted OK.

Now, make ~/mac a link to /mnt/hgfs/mac:

ln -sf /mnt/hgfs/mac ~/mac

and all is well again.

---

Incidentally, I found that copy/paste between host and client no longer worked: another Google search led me to

sudo apt-get install open-vm-tools-desktop

Reboot, and on we go!

Secondary Stack in Cortex GNAT RTS

In GNAT, the secondary stack is a construct used with indeterminate types. For example, if a function returns a String, it isn't possible for the caller to determine how much space to reserve for the result: instead, the called function allocates the amount of space required on the secondary stack, and on return the caller determines how much space to allocate on the normal (primary) stack, and pops the function's result from the secondary stack to there.

This note discusses how the secondary stack is managed in Cortex GNAT RTS for FSF GCC and GNAT Community Edition (was GNAT GPL).