[RFC] Endianness and signals

[RFC] Endianness and signals

[R. Lake]

Further to my study of IA64 architecture, and to an extent the linux kernel,
I wonder if the gate page ought to default to little endian upon issue of a
signal. i.e. "rum 2" prior to any loads/stores? It would seem to me that in
the current state, if the process were preempted immediately after a memory
access (fundamentally) in big-endian mode the signal context would likely
execute in the wrong endianness and fail.  - It's my understanding that the
user mask is preserved in the context switch.

Regards,
Richard.

Re: [RFC] Endianness and signals

[David Mosberger]

>>>>> On Tue, 21 Oct 2003 00:42:09 +0100, "R. Lake" <rich@lakes.plus.com> said:

  Richard> Further to my study of IA64 architecture, and to an extent
  Richard> the linux kernel, I wonder if the gate page ought to
  Richard> default to little endian upon issue of a signal. i.e. "rum
  Richard> 2" prior to any loads/stores? It would seem to me that in
  Richard> the current state, if the process were preempted
  Richard> immediately after a memory access (fundamentally) in
  Richard> big-endian mode the signal context would likely execute in
  Richard> the wrong endianness and fail.  - It's my understanding
  Richard> that the user mask is preserved in the context switch.

I don't think the psABI requires twiddling the PSR.be bit on signal
delivery (though it probably also does not disallow it).  The thing
is, if you have an applications that's completely big-endian, you'd
probably NOT want to clear PSR.be on a signal.  On the other hand, if
you just have one or two routines which turn on PSR.be, then clearing
the bit is clearly advantageous (e.g., would avoid sigprocmask()
calls).  But given that the current kernel behavior has existed for a
long time, I'm not sure it's a good idea to change the behavior now
(it's not like you _can't_ have big-endian code at the moment).

	--david

Re: [RFC] Endianness and signals

[Cary Coutant]

> I don't think the psABI requires twiddling the PSR.be bit on signal
> delivery (though it probably also does not disallow it).  The thing
> is, if you have an applications that's completely big-endian, you'd
> probably NOT want to clear PSR.be on a signal.  On the other hand, if
> you just have one or two routines which turn on PSR.be, then clearing
> the bit is clearly advantageous (e.g., would avoid sigprocmask()
> calls).  But given that the current kernel behavior has existed for a
> long time, I'm not sure it's a good idea to change the behavior now
> (it's not like you _can't_ have big-endian code at the moment).

The psABI doesn't really admit to the existence of mixed-endian 
processes.

I think the right thing to do is set the PSR.be bit on delivery of a 
signal to match (elf_header.e_flags & EF_IA_64_BE). If the process is 
primarily little-endian with an occasional excursion into big-endian 
mode, one would expect (and reasonably require) the application's 
signal handlers to run in little-endian mode. If you've got a 
big-endian process that switches into little-endian mode only to make 
system calls, one would expect its signal handlers to run in big-endian 
mode.

I'm not sure I buy the argument that you shouldn't change the behavior 
now because it's been that way for a long time. What you have now is 
unpredictable, so the only ways a signal handler could work in an 
application that switches the PSR.be bit on a regular basis are: (1) it 
just gets lucky, and never gets an interrupt while in the wrong state, 
(2) the application blocks signals while in the opposite state, or (3) 
the signal handler forces the PSR.be to what it wants. In any of these 
cases, the proposed behavior will work.

-cary

Re: [RFC] Endianness and signals

[David Mosberger]

>>>>> On Tue, 21 Oct 2003 13:37:00 -0700, Cary Coutant <cary@cup.hp.com> said:

  Cary> I think the right thing to do is set the PSR.be bit on
  Cary> delivery of a signal to match (elf_header.e_flags &
  Cary> EF_IA_64_BE).

The kernel does not support the loading of big-endian executables, so
this would be equivalent to always clearing PSR.be on a signal.

  Cary> I'm not sure I buy the argument that you shouldn't change the
  Cary> behavior now because it's been that way for a long time. What
  Cary> you have now is unpredictable, so the only ways a signal
  Cary> handler could work in an application that switches the PSR.be
  Cary> bit on a regular basis are: (1) it just gets lucky, and never
  Cary> gets an interrupt while in the wrong state, (2) the
  Cary> application blocks signals while in the opposite state, or (3)
  Cary> the signal handler forces the PSR.be to what it wants. In any
  Cary> of these cases, the proposed behavior will work.

The fourth case is that the application has signal handlers that
expect to get called in the "opposite" byte-order and those are the
ones that would break if we changed the current behavior.

	--david

Re: [RFC] Endianness and signals

[Cary Coutant]

> The fourth case is that the application has signal handlers that
> expect to get called in the "opposite" byte-order and those are the
> ones that would break if we changed the current behavior.

Do you know of any such applications?

How likely is it that someone would code an application in such a way 
that they guarantee that a certain signal will occur only when 
executing in big-endian mode? (And, conversely, that other signals will 
occur only when executing in little-endian mode?)

If I were writing such an application, and I wanted to figure out what 
to expect when a signal handler is called, my first thought* would be 
to expect it to get called in a standard (i.e., little-endian) mode, no 
matter what. I might then test it and discover that I was wrong. At 
that point, I'd hardly consider that a definitive feature of Linux on 
IA-64; I'd be much more likely to consider it a bug, and bring it to 
someone's attention.

Of course, I realize that most people don't go through that thought 
process -- they assume that the way it works today is the way it will 
always work. I just have a hard time working up any sympathy for those 
people.

By the way, when you arm the signal handler, do you copy the function 
pointer or the function descriptor? Will the user-space code that makes 
the call to the signal handler work if you're in big-endian mode?

-cary

* Actually, my first thought would be to see if it's documented 
somewhere. But this is Linux. :-)

Re: [RFC] Endianness and signals

[David Mosberger]

>>>>> On Tue, 21 Oct 2003 14:57:50 -0700, Cary Coutant <cary@cup.hp.com> said:

  >> The fourth case is that the application has signal handlers that
  >> expect to get called in the "opposite" byte-order and those are
  >> the ones that would break if we changed the current behavior.

  Cary> Do you know of any such applications?

I don't know of _any_ mixed-endian-mode applications for ia64 linux.
It has come up now and then, but I have never seen a strong demand for
it.  That's sort of my point: if you want to do mixed-endian-mode, you
(probably) can do it, but you're pretty much on your own.  It's not
just the kernel, but gdb, libunwind, etc. etc. all of which may or may
not react the "right" way when encountering big-endian data.

  Cary> How likely is it that someone would code an application in
  Cary> such a way that they guarantee that a certain signal will
  Cary> occur only when executing in big-endian mode? (And,
  Cary> conversely, that other signals will occur only when executing
  Cary> in little-endian mode?)

I can certainly imagine an application that switches into big-endian
mode completely before installing any signal handlers.

  Cary> By the way, when you arm the signal handler, do you copy the
  Cary> function pointer or the function descriptor? Will the
  Cary> user-space code that makes the call to the signal handler work
  Cary> if you're in big-endian mode?

We copy the pointer and then dereference it in user-mode (in the trampoline).

Perhaps you misunderstand what I'm saying: I'm not religiously opposed
to making a change in this area, but I'm not going to change it on a
whim.  If someone is serious about supporting mixed-endian-mode
applications, they'll have to put some time into it and at least
answer what happens, e.g., to gdb, etc.

	--david