http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55431
Bug #: 55431
Summary: Invalid auxv search in ppc linux-unwind code.
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bug...@aerifal.cx
config/rs6000/linux-unwind.h contains a function ppc_linux_aux_vector which
searches for the aux vector based on __libc_stack_end; the only use of this
function is to lookup the AT_HWCAP bitfield provided by the kernel. The results
seem to be used only for premature optimization: optimizing out copying
register sets that aren't used on the current cpu model.
Unfortunately, the method used to search for auxv is invalid at the time the
call to ppc_linux_aux_vector is made. The array pointed to by extern char
**environ; may be modified by the application; for example it may be truncated
to clear the environment by writing *environ = 0; In this case, the old,
no-longer-used part of the environ array will be incorrectly interpreted as the
aux vector, causing the unwind code not to find the hwcap values and thus not
to save the register sets it needs to save.
I found this bug while debugging a report that gcc couldn't be built for
powerpc on musl libc due to missing __libc_stack_end symbol. I don't see
anywhere that it's documented that __libc_stack_end points to the original argc
slot passed from the kernel, rather than some arbitrary address between main's
stack frame and argv[], so I think it's very bad design to be relying on this
implementation-detail anyway. The fix I would like to see is the complete
removal of ppc_linux_aux_vector and updating ppc_fallback_frame_state not to
care which register sets are actually in use.
