This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: setjmp on 32b MIPS with 64b FPRs
- From: Steve Ellcey <sellcey at mips dot com>
- To: Yossi Kreinin <yossi dot kreinin at gmail dot com>
- Cc: <newlib at sourceware dot org>
- Date: Mon, 26 Aug 2013 08:53:04 -0700
- Subject: Re: setjmp on 32b MIPS with 64b FPRs
- Authentication-results: sourceware.org; auth=none
- References: <CA+wBbiy7pYh9-ecVBO0OcSMm_jgc6f+4Ateb_Rm7-VXqjeNaPQ at mail dot gmail dot com> <1377289235 dot 5770 dot 116 dot camel at ubuntu-sellcey> <CA+wBbiy0qS4mKZdkJZFD7tZ-n4U1pVgFdcvSkvq-4Tq7eiYsxw at mail dot gmail dot com>
On Sun, 2013-08-25 at 11:31 +0300, Yossi Kreinin wrote:
> Hi,
>
> I'll talk to the person maintaining the newlib build in our company
> and we'll hopefully apply and test the patch together ASAP. In the
> meanwhile, a couple of questions:
>
> 1. #ifdef __mips_fpr=64 - did you mean #if __mips_fpr == 64?
Yes, it should be '#if __mips_fpr == 64'.
>
> 2. I'm guessing the definition of jmp_buf in setjmp.h would need
> fixing as well ("breaking" the ABI - in the sense that currently
> setjmp doesn't save doubles on 32b MIPSes with 64b floats, but perhaps
> that's good enough to work for some apps; and once jmp_buf is
> redefined to have enough space for saved 64b register values, those
> previously working apps would break because they were compiled with
> smaller jmp_bufs and now they're dynamically linked against a libc
> that expects larger jmp_bufs, overwriting whatever it was that those
> apps happened to place right after their jmp_bufs.) What's normally
> done about ABI-breaking fixes in MIPS's libc I don't know - I'm just
> guessing it might be a problem.
You are right, we would need to increase the size of jmp_buf. I will
ask around to see if there is any consensus on what is the best solution
to this.
Steve Ellcey
sellcey@mips.com