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 16:28:04 -0500
User-agent: Microsoft-Entourage/11.1.0.040913

> From: Joerg Wunsch <address@hidden>
>> As Paul Schlie wrote:
>> - yes and no, asm routines would need to manually exclude their use,
>> compiled code would automatically use them or not depending on if
>> the registers were declared as being reserved or not at compile
>> time.
> 
> But only if you recompile the entire library together with your own
> sources.  I haven't heard of anyone else but you who even considered
> that a useful feature.

- has nothing to do with tasteful, it's simply necessary if the result
 is desired. (would be pleased if an alternative exited, but doesn't
 as far as I can tell, short of modifying the target's header file,
 and recompiling the compiler, which would still then necessitate
 the asm routines not to touch the registers being reserved otherwise)

>>> But again, no additional problems for asm sources, they just had
>>> to follow the very same ABI only.
> 
>> - yes. (as long as it defines a hole in the caller-saved register
>> set which asm routines were excluded from being able to use).
> 
> I didn't make an exhaustive test, but so far, I think none of the asm
> code ever uses r2 through r5, so these would be fine candidates (but
> only if you also recompile all the C library functions).  It's kinda
> recommended practice to start allocating global register variables at
> r2 anyway, as the compiler tends to allocate registers ``top down''.

- those are callee (call) saved (globals), they can't be used, it must
  be registers designated as caller-saved (i.e. The local ones that aren't
  saved restored by set/longjump) r18-r27, which I know are generally
  precious, but they're the only ones which would work. (implying that if
  it's a feature that you want to support, likely two of these (I'd
  guess r18/r19 are less painful to loose than than r24-r27) couldn't
  be used by asm support library routines (which I know is likely more
  painful than you may have been expecting). (although C library routines
  wouldn't be excluded if not designated as being reserved)

> As you're the only one requesting this, I wouldn't want to make this
> a formal committment to the ABI though.

- actually there was a bug filed against winavr I believe, but it's
  not a compiler problem.

> Of course, back to the subject, *if* you recompile the entire library
> with your own compiler switch preventing the compiler from ever using
> some register, then just go ahead, and also edit setjmp.S accordingly.
> That should be a trivial job for anyone who considers linking against
> their own specific compilation of the library.  By this, you've simply
> chosen to run your own ABI which might be fine for you, even though
> it's nothing the majority of the users would consider useful -- after
> all, that's why you've got the source code.

- although further complicated by the fact that the asm coded c library
  routines which use those same registers would also need to be recoded,
  again. I won't worry about it, just tried to point out the solution
  to the problem if it were a desired feature, and note that it's not
  a compiler problem, although could be made less painful to support if
  the compiler were tweaked to enable reserved registers to be visible
  to asm routines somehow (or something along those lines).






reply via email to

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