gas 2.16 and assembly macros -- entry_64.S build failure

gas 2.16 and assembly macros -- entry_64.S build failure

[H. Peter Anvin]

On 09/16/2010 04:21 AM, Jan Beulich wrote:
>>
>> Yes, to only generate CFI on binutils that allows us to write sane 
>> looking code.
>>
>> I.e. to disable CONFIG_AS_CFI on binutils that are broken for this.
> 
> Again - that won't help, as it's the macro invocation that gas
> fails one, not one of the actual .cfi_* directives.
> 

Looking again at this issue with the binutils version from hell
(sigh)... I'm running quickly out of ideas.

The problem is that cpp inserts spaces around expansions, so:

	pushq_cfi $(USER_DS)

... turns into something like ...

	pushq_cfi $( ( 5 * 8 + 3 ) )

... which these old versions of gas considers multiple arguments to the
macro, even though there is no comma anywhere.  We can defang *some* of
these problems by using cpp macros to kill them off:

#define pushq_cfi pushq

... but that doesn't work with the macros like movq_cfi.  On those, we
could argue that at least people won't put $ on them, but cpp will still
split them apart with spaces; this apparently causes problems at least
as soon as there is an expression more complicated than addition
involved (apparently plus signs are okay, but minus signs aren't!)

I'm completely lost about how to deal with this.   We can't simply
defang the macros -- at least not in a way that is likely to *stay*
working -- and dropping the macros is seriously going to impact the
debuggability of the kernel.  One way, of course, is to simply declare
binutils 2.16 and 2.15.9x (which is apparently included in
RHEL/CentOS 4) to be broken beyond repair unless distros backport a fix,
and in many ways I think that is the preferred option, but I don't know
if that makes sense to others...

	-hpa

Re: gas 2.16 and assembly macros -- entry_64.S build failure

[Andrew Morton]

On Thu, 30 Sep 2010 17:26:13 -0700 "H. Peter Anvin" <hpa@zytor.com> wrote:

> On 09/16/2010 04:21 AM, Jan Beulich wrote:
> >>
> >> Yes, to only generate CFI on binutils that allows us to write sane 
> >> looking code.
> >>
> >> I.e. to disable CONFIG_AS_CFI on binutils that are broken for this.
> > 
> > Again - that won't help, as it's the macro invocation that gas
> > fails one, not one of the actual .cfi_* directives.
> > 
> 
> Looking again at this issue with the binutils version from hell
> (sigh)... I'm running quickly out of ideas.
> 
> The problem is that cpp inserts spaces around expansions, so:
> 
> 	pushq_cfi $(USER_DS)
> 
> ... turns into something like ...
> 
> 	pushq_cfi $( ( 5 * 8 + 3 ) )
> 
> ... which these old versions of gas considers multiple arguments to the
> macro, even though there is no comma anywhere.

Could we run another little program after cpp which takes the spaces
out again?

Re: gas 2.16 and assembly macros -- entry_64.S build failure

[H. Peter Anvin]

On 09/30/2010 06:01 PM, Andrew Morton wrote:
>>
>> ... which these old versions of gas considers multiple arguments to the
>> macro, even though there is no comma anywhere.
> 
> Could we run another little program after cpp which takes the spaces
> out again?
> 

We could try using the -traditional option to cpp, I don't know if that
would break anything else.  We *used* to use it, and finally got rid of
it...

	-hpa


-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

Re: gas 2.16 and assembly macros -- entry_64.S build failure

[Jan Beulich]

>>> On 01.10.10 at 02:26, "H. Peter Anvin" <hpa@zytor.com> wrote:
> ... but that doesn't work with the macros like movq_cfi.  On those, we

Is that only because of the register names used as operands to
movq_cfi etc not having the % specified right away? I don't think
that is really needed, i.e. the % could go there rather than being
added in the macro body - the .cfi_* directives are perfectly happy
with having the prefix there (and I don't know why it was coded
this way in the first place, as this made it less similar to the plain
movq while I thought the goal was to keep the differences to a
minimum).

> could argue that at least people won't put $ on them, but cpp will still
> split them apart with spaces; this apparently causes problems at least
> as soon as there is an expression more complicated than addition
> involved (apparently plus signs are okay, but minus signs aren't!)
> 
> I'm completely lost about how to deal with this.   We can't simply
> defang the macros -- at least not in a way that is likely to *stay*
> working -- and dropping the macros is seriously going to impact the
> debuggability of the kernel.  One way, of course, is to simply declare
> binutils 2.16 and 2.15.9x (which is apparently included in
> RHEL/CentOS 4) to be broken beyond repair unless distros backport a fix,
> and in many ways I think that is the preferred option, but I don't know
> if that makes sense to others...

The other alternative, albeit disliked by Ingo, continues to be to use
__stringify() on all non-trivial operands, which then wouldn't require
suppressing CONFIG_AS_CFI for pre-2.17 binutils.

Jan

Re: gas 2.16 and assembly macros -- entry_64.S build failure

[H. Peter Anvin]

On 10/01/2010 01:27 AM, Jan Beulich wrote:
>>>> On 01.10.10 at 02:26, "H. Peter Anvin" <hpa@zytor.com> wrote:
>> ... but that doesn't work with the macros like movq_cfi.  On those, we
> 
> Is that only because of the register names used as operands to
> movq_cfi etc not having the % specified right away? I don't think
> that is really needed, i.e. the % could go there rather than being
> added in the macro body - the .cfi_* directives are perfectly happy
> with having the prefix there (and I don't know why it was coded
> this way in the first place, as this made it less similar to the plain
> movq while I thought the goal was to keep the differences to a
> minimum).
> 

No, and in fact the problem that spurred this discussion was in the use
of immediates, not registers:

	pushq_cfi $(USER_DS)

Obviously we can't add the % register prefix, since pushq can take
either a register or an immediate (or, for that matter, a memory operand).

>> could argue that at least people won't put $ on them, but cpp will still
>> split them apart with spaces; this apparently causes problems at least
>> as soon as there is an expression more complicated than addition
>> involved (apparently plus signs are okay, but minus signs aren't!)
>>
>> I'm completely lost about how to deal with this.   We can't simply
>> defang the macros -- at least not in a way that is likely to *stay*
>> working -- and dropping the macros is seriously going to impact the
>> debuggability of the kernel.  One way, of course, is to simply declare
>> binutils 2.16 and 2.15.9x (which is apparently included in
>> RHEL/CentOS 4) to be broken beyond repair unless distros backport a fix,
>> and in many ways I think that is the preferred option, but I don't know
>> if that makes sense to others...
> 
> The other alternative, albeit disliked by Ingo, continues to be to use
> __stringify() on all non-trivial operands, which then wouldn't require
> suppressing CONFIG_AS_CFI for pre-2.17 binutils.

You should be taken out and shot for even thinking that, never mind
putting it in writing...

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

Re: gas 2.16 and assembly macros -- entry_64.S build failure

[Jan Beulich]

>>> On 01.10.10 at 17:21, "H. Peter Anvin" <hpa@zytor.com> wrote:
> On 10/01/2010 01:27 AM, Jan Beulich wrote:
>>>>> On 01.10.10 at 02:26, "H. Peter Anvin" <hpa@zytor.com> wrote:
>>> ... but that doesn't work with the macros like movq_cfi.  On those, we
>> 
>> Is that only because of the register names used as operands to
>> movq_cfi etc not having the % specified right away? I don't think
>> that is really needed, i.e. the % could go there rather than being
>> added in the macro body - the .cfi_* directives are perfectly happy
>> with having the prefix there (and I don't know why it was coded
>> this way in the first place, as this made it less similar to the plain
>> movq while I thought the goal was to keep the differences to a
>> minimum).
>> 
> 
> No, and in fact the problem that spurred this discussion was in the use
> of immediates, not registers:
> 
> 	pushq_cfi $(USER_DS)
> 
> Obviously we can't add the % register prefix, since pushq can take
> either a register or an immediate (or, for that matter, a memory operand).

Perhaps a misunderstanding? I meant to move the % back into
movq_cfi's arguments, out of the macro body. pushq_cfi already
is in the shape we need for having the option of using cpp macros
when !CONFIG_AS_CFI.

>> The other alternative, albeit disliked by Ingo, continues to be to use
>> __stringify() on all non-trivial operands, which then wouldn't require
>> suppressing CONFIG_AS_CFI for pre-2.17 binutils.
> 
> You should be taken out and shot for even thinking that, never mind
> putting it in writing...

Thank you!

Jan

Re: gas 2.16 and assembly macros -- entry_64.S build failure

[H. Peter Anvin]

On 10/01/2010 08:46 AM, Jan Beulich wrote:
> 
> Perhaps a misunderstanding? I meant to move the % back into
> movq_cfi's arguments, out of the macro body. pushq_cfi already
> is in the shape we need for having the option of using cpp macros
> when !CONFIG_AS_CFI.
> 

Hm... I guess I'm not quite following.  I don't really see how that
would help with movq_cfi, though?

>>> The other alternative, albeit disliked by Ingo, continues to be to use
>>> __stringify() on all non-trivial operands, which then wouldn't require
>>> suppressing CONFIG_AS_CFI for pre-2.17 binutils.
>>
>> You should be taken out and shot for even thinking that, never mind
>> putting it in writing...
> 
> Thank you!

Just in case the intended sarcasm didn't read... I was of course joking,
although in all seriousness the __stringify() truly is
stick-your-eyes-out ugly and is just begging for future problems.  It
really isn't an option.

	-hpa

Re: gas 2.16 and assembly macros -- entry_64.S build failure

[Jan Beulich]

>>> On 01.10.10 at 19:21, "H. Peter Anvin" <hpa@zytor.com> wrote:
> On 10/01/2010 08:46 AM, Jan Beulich wrote:
>> 
>> Perhaps a misunderstanding? I meant to move the % back into
>> movq_cfi's arguments, out of the macro body. pushq_cfi already
>> is in the shape we need for having the option of using cpp macros
>> when !CONFIG_AS_CFI.
>> 
> 
> Hm... I guess I'm not quite following.  I don't really see how that
> would help with movq_cfi, though?

Oh, sorry, I overlooked that the macro is also attaching (%rsp)
to the second operand. So what I said would only apply to
movq_cfi_restore (where \offset really isn't used without the
(%rsp), and hence this can also be moved back out of the macro
body).

For movq_cfi it may require some playing with .irpc to achieve the
same (due to there not being any string manipulation operations
in gas). I'm pretty sure it can be made work, but it'll look ugly
(and/or may require insertion of a space between the offset
expression and the (%rsp)).

Jan

Re: gas 2.16 and assembly macros -- entry_64.S build failure

[Avi Kivity]

  On 10/01/2010 02:26 AM, H. Peter Anvin wrote:
> ... but that doesn't work with the macros like movq_cfi.  On those, we
> could argue that at least people won't put $ on them, but cpp will still
> split them apart with spaces; this apparently causes problems at least
> as soon as there is an expression more complicated than addition
> involved (apparently plus signs are okay, but minus signs aren't!)

Likely due to the fact that a minus sign can later join with a number 
and become a new token, but a plug sign cannot.

-- 
error compiling committee.c: too many arguments to function

Re: gas 2.16 and assembly macros -- entry_64.S build failure

[H. Peter Anvin]

On 10/04/2010 03:04 AM, Avi Kivity wrote:
>  On 10/01/2010 02:26 AM, H. Peter Anvin wrote:
>> ... but that doesn't work with the macros like movq_cfi.  On those, we
>> could argue that at least people won't put $ on them, but cpp will still
>> split them apart with spaces; this apparently causes problems at least
>> as soon as there is an expression more complicated than addition
>> involved (apparently plus signs are okay, but minus signs aren't!)
> 
> Likely due to the fact that a minus sign can later join with a number
> and become a new token, but a plug sign cannot.
> 

... except the same thing applies to other operators, other than the
plus sign.  This kind of characterization is insanely frustrating, and
really doesn't seem to follow logical rules ... we had a previous one
where changing a macro name from upper case to lower case made gas 2.16
work...
	
	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

Re: gas 2.16 and assembly macros -- entry_64.S build failure

[Avi Kivity]

  On 10/04/2010 05:43 PM, H. Peter Anvin wrote:
> On 10/04/2010 03:04 AM, Avi Kivity wrote:
> >   On 10/01/2010 02:26 AM, H. Peter Anvin wrote:
> >>  ... but that doesn't work with the macros like movq_cfi.  On those, we
> >>  could argue that at least people won't put $ on them, but cpp will still
> >>  split them apart with spaces; this apparently causes problems at least
> >>  as soon as there is an expression more complicated than addition
> >>  involved (apparently plus signs are okay, but minus signs aren't!)
> >
> >  Likely due to the fact that a minus sign can later join with a number
> >  and become a new token, but a plug sign cannot.
> >
>
> ... except the same thing applies to other operators, other than the
> plus sign.  This kind of characterization is insanely frustrating, and
> really doesn't seem to follow logical rules ... we had a previous one
> where changing a macro name from upper case to lower case made gas 2.16
> work...
> 	

Well, / and * do join.  % doesn't.  In a way, + does.

cpp is not a pure text processing language.  It's specifically geared to 
C, and is fairly creaky when applying it to something other than C (and 
is only somewhat creaky when applying it to C).

-- 
error compiling committee.c: too many arguments to function

Re: gas 2.16 and assembly macros -- entry_64.S build failure

[H. Peter Anvin]

On 10/04/2010 09:20 AM, Avi Kivity wrote:
>   On 10/04/2010 05:43 PM, H. Peter Anvin wrote:
>> On 10/04/2010 03:04 AM, Avi Kivity wrote:
>>>   On 10/01/2010 02:26 AM, H. Peter Anvin wrote:
>>>>  ... but that doesn't work with the macros like movq_cfi.  On those, we
>>>>  could argue that at least people won't put $ on them, but cpp will still
>>>>  split them apart with spaces; this apparently causes problems at least
>>>>  as soon as there is an expression more complicated than addition
>>>>  involved (apparently plus signs are okay, but minus signs aren't!)
>>>
>>>  Likely due to the fact that a minus sign can later join with a number
>>>  and become a new token, but a plug sign cannot.
>>>
>>
>> ... except the same thing applies to other operators, other than the
>> plus sign.  This kind of characterization is insanely frustrating, and
>> really doesn't seem to follow logical rules ... we had a previous one
>> where changing a macro name from upper case to lower case made gas 2.16
>> work...
>> 	
> 
> Well, / and * do join.  % doesn't.  In a way, + does.
> 
> cpp is not a pure text processing language.  It's specifically geared to 
> C, and is fairly creaky when applying it to something other than C (and 
> is only somewhat creaky when applying it to C).
> 

The problem isn't with cpp, though, it's with gas.  There are bugs in
the gas 2.16 macro features that don't apply to any other gas version,
before *or* after.

	-hpa

Re: gas 2.16 and assembly macros -- entry_64.S build failure

[Avi Kivity]

  On 10/04/2010 08:23 PM, H. Peter Anvin wrote:
> On 10/04/2010 09:20 AM, Avi Kivity wrote:
> >    On 10/04/2010 05:43 PM, H. Peter Anvin wrote:
> >>  On 10/04/2010 03:04 AM, Avi Kivity wrote:
> >>>    On 10/01/2010 02:26 AM, H. Peter Anvin wrote:
> >>>>   ... but that doesn't work with the macros like movq_cfi.  On those, we
> >>>>   could argue that at least people won't put $ on them, but cpp will still
> >>>>   split them apart with spaces; this apparently causes problems at least
> >>>>   as soon as there is an expression more complicated than addition
> >>>>   involved (apparently plus signs are okay, but minus signs aren't!)
> >>>
> >>>   Likely due to the fact that a minus sign can later join with a number
> >>>   and become a new token, but a plug sign cannot.
> >>>
> >>
> >>  ... except the same thing applies to other operators, other than the
> >>  plus sign.  This kind of characterization is insanely frustrating, and
> >>  really doesn't seem to follow logical rules ... we had a previous one
> >>  where changing a macro name from upper case to lower case made gas 2.16
> >>  work...
> >>  	
> >
> >  Well, / and * do join.  % doesn't.  In a way, + does.
> >
> >  cpp is not a pure text processing language.  It's specifically geared to
> >  C, and is fairly creaky when applying it to something other than C (and
> >  is only somewhat creaky when applying it to C).
> >
>
> The problem isn't with cpp, though, it's with gas.  There are bugs in
> the gas 2.16 macro features that don't apply to any other gas version,
> before *or* after.

I see.

I suppose it isn't possible to refuse to build with the broken version?

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

Re: gas 2.16 and assembly macros -- entry_64.S build failure

[Ingo Molnar]

* Avi Kivity <avi@redhat.com> wrote:

>  On 10/04/2010 08:23 PM, H. Peter Anvin wrote:
> >On 10/04/2010 09:20 AM, Avi Kivity wrote:
> >>    On 10/04/2010 05:43 PM, H. Peter Anvin wrote:
> >>>  On 10/04/2010 03:04 AM, Avi Kivity wrote:
> >>>>    On 10/01/2010 02:26 AM, H. Peter Anvin wrote:
> >>>>>   ... but that doesn't work with the macros like movq_cfi.  On those, we
> >>>>>   could argue that at least people won't put $ on them, but cpp will still
> >>>>>   split them apart with spaces; this apparently causes problems at least
> >>>>>   as soon as there is an expression more complicated than addition
> >>>>>   involved (apparently plus signs are okay, but minus signs aren't!)
> >>>>
> >>>>   Likely due to the fact that a minus sign can later join with a number
> >>>>   and become a new token, but a plug sign cannot.
> >>>>
> >>>
> >>>  ... except the same thing applies to other operators, other than the
> >>>  plus sign.  This kind of characterization is insanely frustrating, and
> >>>  really doesn't seem to follow logical rules ... we had a previous one
> >>>  where changing a macro name from upper case to lower case made gas 2.16
> >>>  work...
> >>>  	
> >>
> >>  Well, / and * do join.  % doesn't.  In a way, + does.
> >>
> >>  cpp is not a pure text processing language.  It's specifically geared to
> >>  C, and is fairly creaky when applying it to something other than C (and
> >>  is only somewhat creaky when applying it to C).
> >>
> >
> >The problem isn't with cpp, though, it's with gas.  There are bugs in
> >the gas 2.16 macro features that don't apply to any other gas version,
> >before *or* after.
> 
> I see.
> 
> I suppose it isn't possible to refuse to build with the broken version?

We could leave it build-broken and ask for a version specific quirk that 
runs a simple sed script over the source to turns 'pushl_cfi' et al into 
'push', or so?

Thanks,

	Ingo

Re: gas 2.16 and assembly macros -- entry_64.S build failure

[Avi Kivity]

  On 10/05/2010 09:51 AM, Ingo Molnar wrote:
> >
> >  I suppose it isn't possible to refuse to build with the broken version?
>
> We could leave it build-broken and ask for a version specific quirk that
> runs a simple sed script over the source to turns 'pushl_cfi' et al into
> 'push', or so?
>

Good idea.

-- 
error compiling committee.c: too many arguments to function

Re: gas 2.16 and assembly macros -- entry_64.S build failure

[Jan Beulich]

>>> On 01.10.10 at 02:26, "H. Peter Anvin" <hpa@zytor.com> wrote:
> On 09/16/2010 04:21 AM, Jan Beulich wrote:
>>>
>>> Yes, to only generate CFI on binutils that allows us to write sane 
>>> looking code.
>>>
>>> I.e. to disable CONFIG_AS_CFI on binutils that are broken for this.
>> 
>> Again - that won't help, as it's the macro invocation that gas
>> fails one, not one of the actual .cfi_* directives.
>> 
> 
> Looking again at this issue with the binutils version from hell
> (sigh)... I'm running quickly out of ideas.
> 
> The problem is that cpp inserts spaces around expansions, so:
> 
> 	pushq_cfi $(USER_DS)
> 
> ... turns into something like ...
> 
> 	pushq_cfi $( ( 5 * 8 + 3 ) )
> 
> ... which these old versions of gas considers multiple arguments to the
> macro, even though there is no comma anywhere.  We can defang *some* of
> these problems by using cpp macros to kill them off:
> 
> #define pushq_cfi pushq
> 
> ... but that doesn't work with the macros like movq_cfi.  On those, we
> could argue that at least people won't put $ on them, but cpp will still
> split them apart with spaces; this apparently causes problems at least
> as soon as there is an expression more complicated than addition
> involved (apparently plus signs are okay, but minus signs aren't!)
> 
> I'm completely lost about how to deal with this.   We can't simply
> defang the macros -- at least not in a way that is likely to *stay*
> working -- and dropping the macros is seriously going to impact the
> debuggability of the kernel.  One way, of course, is to simply declare
> binutils 2.16 and 2.15.9x (which is apparently included in
> RHEL/CentOS 4) to be broken beyond repair unless distros backport a fix,
> and in many ways I think that is the preferred option, but I don't know
> if that makes sense to others...

Would excessive parenthesisation (in the header files) be an
acceptable workaround? cpp inserts the spaces only when
a preprocessing identifier that expands to a token sequence
ending in a number is followed by ., +, or -. (The asymmetry
in behavior between + and - then results from gas considering
- a symbol char, but not +, which is the case even in current
mainline, and which I think ought to be fixed - I'll bring this
up on their mailing list -, but that fix would break the kernel
build in its current shape afaict.)

Basically, all constants potentially used in assembly expressions
passed to macros would need to change from e.g.

#define RIP		128

to

#define RIP		(128)

I'll put together a patch if this is considered acceptable, and if
it turns out to work across all cpp/gas version combinations
that I can reasonably try.

Jan

Re: gas 2.16 and assembly macros -- entry_64.S build failure

[Ingo Molnar]

* Jan Beulich <JBeulich@novell.com> wrote:

> >>> On 01.10.10 at 02:26, "H. Peter Anvin" <hpa@zytor.com> wrote:
> > On 09/16/2010 04:21 AM, Jan Beulich wrote:
> >>>
> >>> Yes, to only generate CFI on binutils that allows us to write sane 
> >>> looking code.
> >>>
> >>> I.e. to disable CONFIG_AS_CFI on binutils that are broken for this.
> >> 
> >> Again - that won't help, as it's the macro invocation that gas
> >> fails one, not one of the actual .cfi_* directives.
> >> 
> > 
> > Looking again at this issue with the binutils version from hell
> > (sigh)... I'm running quickly out of ideas.
> > 
> > The problem is that cpp inserts spaces around expansions, so:
> > 
> > 	pushq_cfi $(USER_DS)
> > 
> > ... turns into something like ...
> > 
> > 	pushq_cfi $( ( 5 * 8 + 3 ) )
> > 
> > ... which these old versions of gas considers multiple arguments to the
> > macro, even though there is no comma anywhere.  We can defang *some* of
> > these problems by using cpp macros to kill them off:
> > 
> > #define pushq_cfi pushq
> > 
> > ... but that doesn't work with the macros like movq_cfi.  On those, we
> > could argue that at least people won't put $ on them, but cpp will still
> > split them apart with spaces; this apparently causes problems at least
> > as soon as there is an expression more complicated than addition
> > involved (apparently plus signs are okay, but minus signs aren't!)
> > 
> > I'm completely lost about how to deal with this.   We can't simply
> > defang the macros -- at least not in a way that is likely to *stay*
> > working -- and dropping the macros is seriously going to impact the
> > debuggability of the kernel.  One way, of course, is to simply declare
> > binutils 2.16 and 2.15.9x (which is apparently included in
> > RHEL/CentOS 4) to be broken beyond repair unless distros backport a fix,
> > and in many ways I think that is the preferred option, but I don't know
> > if that makes sense to others...
> 
> Would excessive parenthesisation (in the header files) be an
> acceptable workaround? cpp inserts the spaces only when
> a preprocessing identifier that expands to a token sequence
> ending in a number is followed by ., +, or -. (The asymmetry
> in behavior between + and - then results from gas considering
> - a symbol char, but not +, which is the case even in current
> mainline, and which I think ought to be fixed - I'll bring this
> up on their mailing list -, but that fix would break the kernel
> build in its current shape afaict.)
> 
> Basically, all constants potentially used in assembly expressions
> passed to macros would need to change from e.g.
> 
> #define RIP		128
> 
> to
> 
> #define RIP		(128)
> 
> I'll put together a patch if this is considered acceptable, and if
> it turns out to work across all cpp/gas version combinations
> that I can reasonably try.

We already have cases of such parenthesisation - so i suspect it would be 
acceptable, if it doesnt affect an unacceptably excessive number of constants.

Thanks,

	Ingo