The unwindability cannot be guaranteed for all millicode calls because the
assembler cannot automatically generate the standard entry and exit sequences
for millicode routines that utilize stack space. This does not present a major
problem because relatively few millicode routines create a stack frame. It is
possible, however, to support unwinding from such situations (i.e. nested
millicode calls), provided that a millicode routine that allocates stack space
is written so that it will independently generate the correct entry and exit
sequences. It is the responsibility of the author of the specific routine to
incorporate these sequences into the actual code.
Also, on HP-UX, millicode resides not as a separate shared library, but as a
part of each shared library. Hence one would not encounter any stubs while
unwinding from millicode routines. This is also true on MPE XL when internal
millicode is used. Each load module has its own copy of millicode.
Unwinding from external millicode is slightly different than code or normal
millicode because sr4 does not track PC's SID. sr0 and gr31 are used to return
to the caller. Both these values must be stored if nested millicode calls are
done. (This is currently done for internal millicode too, since the
Save_RP bit is set instead of Save_MRP_in_frame.) External
millicode and the unwind descriptors for external millicode must be at an
architected location. This allows unwinding a mixture of internal and external
millicode.
It is likely that stack traces may also hide the call to millicode because
application programmers do not see millicode as a separate entity.
Complete PDF