Re: hppa ocaml build failure :(((
On Mon, Oct 13, 2003 at 06:27:43PM +0200, Sven Luther wrote:
> On Mon, Oct 13, 2003 at 09:04:49AM -0600, LaMont Jones wrote:
> > On Mon, Oct 13, 2003 at 10:09:17AM +0200, Sven Luther wrote:
> > > On Mon, Oct 13, 2003 at 09:41:35AM +0200, Stefano Zacchiroli wrote:
> > > > On Mon, Oct 13, 2003 at 09:17:59AM +0200, Sven Luther wrote:
> > > Ok, but now we have the hppa autobuilder maintainer looking at it
> > > (hopefully) so we will know more about it. I CC him on this mail, so he
> > > will know about your experience.
> Cool, but i suppose this means the problem is not really solved, right ?
That or ocaml works around it...
> > it down. The unaligned handler does somewhat throttled printks (They're
> > only throttled within the process, running another one will keep them
> > coming.) With as many as ocaml's build was generating, I expect that was
> > why the system was crashing.
> So a kernel issue ?
That part is. Basically an ocaml? feature? exercising a kernel defect.
Two independent problems working together to make my life difficult... :-)
> That feels strange, since on hppa, only the bytecode compiler is
> available, and the bytecode stuff, to the best of my knowledge, has
> everything 32bit aligned. ... Mmm, you are speaking about 16 byte (as in
> 16 x 8 = 128 bit alignement ?). I will investigate with upstream for
> this. Is this only for floats, or for everything ?
fstd (128 bit store) is used in setjmp to save state - unless ocaml is
generating its own hppa assembly (and using fstd...), then it's elsewhere.
I'm not aware of the compiler generating that instr other than when doing
quad floats.
> Also, if there needs to be a change in ocaml, would it be possible to
> have an account for upstream on a hppa box so he can track (and fix) the
> issue ?
We should be able to arrange this. One should poke taggart or willy to create
the account on paer (or some other parisc box at hp...)
> > But again, it seems to be working now, at least on machines that raise
> > SIGBUS on unaligned loads/stores.
> Ok, but may be broken again in the future, best would be to solve this
> for in ocaml if possible.
And it may crash machines that don't raise it... It would be good to fix.
lamont
Reply to: