avr-libc-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-libc-dev] [bugs #4101] setjmp/longjmp destroy changes in global


From: Paul Schlie
Subject: Re: [avr-libc-dev] [bugs #4101] setjmp/longjmp destroy changes in global registers
Date: Mon, 17 Jan 2005 14:55:53 -0500
User-agent: Microsoft-Entourage/11.1.0.040913

> From: Joerg Wunsch <address@hidden>
>> As Paul Schlie wrote:
>> Sorry, as I may misunderstand, doesn't the 1/10/05 patch fix the
>> problem?
> 
> October 1, 2005 is still in the future. ;-)
> 
> Seriously, better use ISO dates (2005-01-10) when talking on
> international mailing lists, to avoid ambiguities.  Remember that not
> even the British and American people agree on a common format, let
> alone the remaining 95 % of the world.  (No, 2005-01-10 isn't our
> native date format either, we used to write 10.01.2005, but the ISO
> format is simply avoiding any possible confusion, so I prefer it over
> our native format now.)

Then you may want to tweak the formatting used in the bug tracking log:

 -------------------------------------------------------
 Date: Sun 01/16/05 at 18:30         By: Joerg Wunsch <joerg_wunsch>
 As there is currently no fix in sight that would not break

 legitimate programs, I documented the problem.
 
 -------------------------------------------------------
 Date: Mon 01/10/05 at 06:07         By: Anonymous
 Final (I hope) version of modifyed setjmp (20050110).
 Test set is expanded.
 
 Shortly: saving/restoring registers r2-r17 is excluded from setjmp.
 
(I too prefer 2005-01-10, as it sorts alphabetically ascending)

> No, the latest patch worked only for GCC < 3.4.x, so we can by now
> only document the current behaviour.  GCC >= 3.4.x doesn't save the
> global registers when seeing a setjmp() as previous versions obviously
> used to do.  Thus, setjmp/longjmp need to do this, and we're out of
> luck for global register variables.

Is it possible you've got this backward? As I understand it, the fix is
appropriate for all newer releases GCC >= 3.4, (i.e. 3.4.x and pending
4.0.x), which should assume responsibility for saving global registers as
required, where the callee should only be responsible for saving it's local
register state, as would be also required for global register declarations
to work properly, as they should be simply eliminated from the eliminated
global register allocation pool? 






reply via email to

[Prev in Thread] Current Thread [Next in Thread]