This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [commit] Use -mabi=altivec for AltiVec tests
On Sun, Oct 21, 2007 at 08:07:57PM +0200, Ulrich Weigand wrote:
> Sorry, I didn't consider this controversial, or I would have posted an RFC
> first ... I understand it to be general practice to use -mabi=altivec
> with applications on Linux, and that should be OK as long as no system
> library interface using vector arguments is used. Is this a problem
> in other environments?
>
> However, if you prefer, I certainly have no objections to reverting the
> patch (or maybe restricting it to Linux only) ...
My understanding (courtesy of Geoff Keating) is that on most PowerPC
targets this only affects the passing of vector registers. On some
(powerpc-eabi; I am not sure if there are others, but I do not know
of any) it increases the required stack alignment. If your CRT files
don't do this, then saving the vector registers may do bad things
to your stack frame.
I know my local GDB works both with -mabi=altivec and without it,
because I run this test in two multilibs :-)
For now, what do you think we should do about the option? Restrict it
to Linux?
> > Unfortunately the linker patch is hung up right now because it notices
> > this same dubious action (linking -mabi=altivec and -mabi=no-altivec
> > code) and warns about it. That causes a bunch of GCC testcase
> > failures. The GCC testcases in question use, but do not actually
> > need, -mabi=altivec; they just need a nasty bug in -maltivec
> > -mabi=no-altivec fixed and my patch for that didn't get any comments
> > :-(
>
> Can you point me to the patch in question? Maybe I can ping David ...
http://gcc.gnu.org/ml/gcc-patches/2007-08/msg00438.html
Perhaps I should ping that now that the .gnu_attribute bit went in
separately. Actually, no, the patch predated my improved
understanding of the stack alignment magic. It might be right
for powerpc-eabi, but powerpc-linux actually does have a sufficiently
aligned stack so it ought to save them properly.
--
Daniel Jacobowitz
CodeSourcery