Re: Dealing with unaligned accesses
On Fri, Dec 04, 1998 at 07:48:33AM +0200, Aki Matias Nyrhinen wrote:
> > In reading the message for an unaligned access, I'd like some
> > clarification regarding the kernel message. I figure the first number
> > is the address where the access occured. Right? Is this the address
> > of the first byte of the instruction that generated the unaligned
> > access? I guess the second number is the address it is accessing
> > unaligned. What are the two bytes that follow?
>
> You are seeing something like this ?
> vim(2379): unaligned trap at 00000001200597e4: 00000001201a72a4 27 1
>
> These are a problem, and should be eliminated :)
>
> Anyway, The kernel source says:
>
> printk("%s(%d): unaligned trap at %016lx: %p %lx %ld\n",current->comm,
> current->pid, regs->pc - 4, va, opcode, reg);
>
> > If this is correct, the bad access I am seeing is a br instruction
> > which I believe is an unconditional branch. (My reference book is for
> > DEC opcodes, so I'm guessing here.)
>
> Umm, That can't be true, I guess. Unaligned access means that some data is
> being loaded from an unaligned address (addr%8 != 0) Alpha want's memory
> accesses to be 64bit-aligned. There's some PALcode-stuff to handle this
> (through the exception), but that is very slow anyway, and the Acrhitecture
> reference book suggests that an OS should inform the user that he/she is
> taking a great performance hit.
ITOT the instruction is not the br, but the instruction before it.
I'm not sure why, but my calculations from the symbol table and GAS
output are not as accurate as the GDB loaded image.
Indeed, these are problems that should be fixed.
It was an error in a macro calculation. I'll post the patch in a few
minutes.
Reply to: