public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
* VAX PC RELATIVE JMP: gas and gdb perform incorrect sign extension
@ 2000-08-21 11:58 John David Anglin
  0 siblings, 0 replies; only message in thread
From: John David Anglin @ 2000-08-21 11:58 UTC (permalink / raw)
  To: binutils, gdb

In trying to build the current cvs version of gcc, I discovered an
obviously long standing bug in the treatment of long pc relative
branches on the vax.  The following code snippet from expand_expr
is incorrectly assembled by gas:

		tstl	r9
		jeql	L2956
		clrl	-(sp)

L2956 is more than 32K bytes back in the code.  After linking, I
see the following with adb:

		tstl	r9
		bneq	0xb4f06
		jmp	0xbf867	; wrong location
0xb4f06:	clrl	-(sp)

The `jmp' actually goes to 0xbf867, so I believe the adb disassembly.
However, when I look with gdb, I get:

                tstl    r9
		bneq    0xb4f06
		jmp     0xaf867 ; location of L2956
0xb4f06:        clrl    -(sp)

The hex value of the pc relative address is 0xa961 (0xb4f06 + 0xa961 =
0xbf867).  However, gas and gdb seem to think that the vax will sign
extend the word 0xa961 to the long word 0xffffa961 (0xb4f06 + 0xffffa961 =
0xaf867).  This is clearly wrong.  The correct offset is 0xffffa961.

The error is present in expr.o, so it is not the linker which causes it.
I am looking at the binutils code.  Suggestions on where to look are welcome.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2000-08-21 11:58 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-08-21 11:58 VAX PC RELATIVE JMP: gas and gdb perform incorrect sign extension John David Anglin

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).