jkp@sauna.hut.fi (Jyrki Kuoppala) (03/10/91)
Gcc docs tell that the ns32k series has a bug with operands crossing page boundaries. This is why STRICT_ALIGNMENT is defined in tm-ns32k.h. Could someone tell me whether the bug still is in the 32532 ? Currently I don't define STRICT_ALIGNMENT in tm-pc532.h and haven't run into trouble (well, I had some strange crashes when debugging programs but I account them to my ptrace support which is not that much tested yet). But if the bug still exists, I'll have to define STRICT_ALIGNMENT. //Jyrki
jvh@galactus.hut.fi (Johannes Helander) (03/13/91)
Jonathan Ryshpan <halsoft!jon@hitachi.uucp> writes: > As I remember it, the problem was that instructions line NEG produced a > read cycle followed by a write cycle instead of a read-modify-write > cycle. This broke copy on write (for forks), for reasons I don't > remember. I don't know whether the ns532 has fixed this or not. Dave > Rand?? [I think I mentioned this already some time ago, so sorry for boring you] At least when a sbiti (interlocked set bit) instruction page faults will the msr contain an incorrect value. The only way to find out that the trap was in fact caused by a read-modify-write cycle is to look at the instruction itself (check if it is sbiti). This can of course be optimized by saving the address and by looking at the instruction only when the previous address was the same. Anyway still ugly. Are there other known situations when this may happen? It is of no help to look at the instruction if not knowing what to look at. What is meant by 'instructions line NEG'? Do I smell trouble? The problem with copy on write here is that no unnecessary write access will be given. If the page fault handler is presented with a read fault, it will just upgrade the access to read. Then the instruction will again read fault, it will gain read access, fault,... ad infinitum. It is thus necessary to correctly recognize write faults even when the harware is lying about them. To recognize such a situation the situation must be known. Some check could of course be added to panic the operating system (and report that it found a hardware bug) or something similar if the same instruction causes a read trap over and over again. Are there other known bugs (except movus/movsu using both ptbs even in single address space mode)? Does anyone have a buglist? Johannes