Re: How should -ffixed-@var{reg} global registers be identifiedfor setjump coding?

[Paul Schlie <schlie at comcast dot net>]

Thank you, but if the declared global-registers are consistently declared
at compile-time, including during the compile of an in-line asm coding of
set/longjump (i.e. not embedded in a pre-compiled library), then as long as
they can be procedurally identified, as the register allocator is hopefully
doing to avoid using them itself, they should be able to be correspondingly
identified and excluded from the save/restore jumpbuf state during its
compilation if enabled through the use of a __reserved compiler function
call or shared variable hopefully (I would like to think/hope), as otherwise
the use of compile-time global registers and set/longjump like functionality
is needlessly otherwise mutually exclusive, even if compiled with the same
compile-time switches?

(if there is no present method by which a source file can access this
compiler defined data, is their a recommended method to define new reserved
__function calls which may be invoked by a source file to access private
compiler data?)

> From: Ramana Radhakrishnan <ramana.r@gmail.com>
> This was raised in the mailing list earlier this month .
> http://gcc.gnu.org/ml/gcc/2005-01/msg00902.html contains the reply .
> 
> Its not possible for ffixed-reg to be used with setjmp / longjmp with
> the features that you want right now AFAIK. The reply to that thread
> deals with a case that you might like to see.
> 
>> On Sat, 29 Jan 2005 23:53:53 -0500, Paul Schlie <schlie@comcast.net> wrote:
>> Although it may be staring me in the face, what's is the proper method
>> to identify compile-time -ffixed-@var{reg} declared global-registers
>> so that they may be properly excluded from being saved/restored by a
>> set/longjump routine implementation?
>> 
>> Any insight would be appreciated, thanks, -paul-