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, 07 Feb 2005 11:34:05 -0500
User-agent: Microsoft-Entourage/11.1.0.040913

> From: Joerg Wunsch <address@hidden>
>> As Paul Schlie wrote:
>> - ok, I accept that possibility; please correct my misunderstanding.
> 
> We basically implement the ABI you're suggesting.

- which is good, even if only by accident; but it needs to be documented
  which subset of caller-saved registers are safe/prefered to use, if
  desired, and are considered officially not available for asm code use.

> Review the entire thread, including Dmitry's testsuit, as well as his
> findings about how the various GCC version do/don't save registers
> when setjmp is called within a function.  If GCC worked the way GCC
> 3.3.x did, we could make setjmp/longjmp cooperative with global
> register variables.

- read the thread, but don't see how it could ever have worked, as there's
  nothing in the set/longjump implementation which could signal gcc to
  save the callee-saved registers, less the compile-time declared ones
  into the routine's defined jump-buf; nor is there's a mechanism for
  gcc to indicate to the asm routine which registers need saving vs not?
  (so although I don't deny it previously worked properly, I just don't see
   how it could have?)

> It appears to me that you somehow suffer from the miscomprehension
> that avr-libc were mostly implemented in assembler,

- not at all.

>  and that all of our problems arise just out of this situation.

- also not at all, just pointed out that if asm coding is utilized,
  it must be restricted to some subset of the available caller-saved
  registers for the documented gcc global reserved register feature to
  work. (thereby enabling set/longjump to be used safely with compile
  time declared reserved global registers if correspondingly restricted.
  (although admit it would be nicer if they could be allocated out of
   the callee-saved pool, but it's not presently supported by gcc)

> While we do have a lot
> of assembler files (I'm not particularly happy with the situation
> either, e.g. fplib is rather hard to maintain), they follow the exact
> same ABI as the C compiler, so I don't see any difference in that.

- almost, the compiler can/will avoid using compile-time declared reserved
  global registers; asm routines can't, therefore must restrict their
  their use in anticipation of the possibility, regardless if they're
  used or not. (as in fact the ABI is actually somewhat soft, not hard)

> -- 






reply via email to

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