NetBSD Problem Report #20924

Received: (qmail 9362 invoked by uid 605); 28 Mar 2003 19:58:05 -0000
Message-Id: <20030328195803.8DB11292C2@smistad.uninett.no>
Date: Fri, 28 Mar 2003 20:58:03 +0100 (CET)
From: he@netbsd.org
Sender: gnats-bugs-owner@netbsd.org
Reply-To: he@netbsd.org
To: gnats-bugs@gnats.netbsd.org
Subject: vax assembler checking for byte offsets causes build error
X-Send-Pr-Version: 3.95

>Number:         20924
>Category:       toolchain
>Synopsis:       vax assembler checking for byte offsets causes build error
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    matt
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Mar 28 19:59:00 +0000 2003
>Closed-Date:    Thu Oct 20 07:39:46 +0000 2016
>Last-Modified:  Thu Oct 20 07:39:46 +0000 2016
>Originator:     Havard Eidnes <he@netbsd.org>
>Release:        NetBSD 1.6Q Mar 28 2003
>Organization:
	Unorganized, Inc.
>Environment:
Host system: NetBSD stegg.urc.uninett.no 1.6P NetBSD 1.6P (STEGG.MP) #1: Fri Mar 14 14:58:00 CET 2003  he@stegg.urc.uninett.no:/sys/arch/i386/compile/STEGG.MP i386
Architecture: vax
Machine: vax
>Description:
	Assembly of intvec.S fails with error:

/usr/tools/bin/vax--netbsdelf-gcc  -x assembler-with-cpp -traditional-cpp -mno-asm-pic -D_LOCORE  -D_VAX_INLINE_ -I.  -I/usr/users/he/src/sys/arch -I/usr/users/he/src/sys -nostdinc -DLKM -DMAXUSERS=8 -D_KERNEL -D_KERNEL_OPT -c /usr/users/he
/src/sys/arch/vax/vax/intvec.S
/usr/users/he/src/sys/arch/vax/vax/intvec.S: Assembler messages:
/usr/users/he/src/sys/arch/vax/vax/intvec.S:246: Error: value of -721 too large for field of 1 bytes at 720
*** Error code 1

Stop.

	Matt Thomas recommended use of "jbr" or "brw" instead of "brb"
	as a workaround, which is going to be committed shortly.

	I'm uncertain as to whether it's appropriate for the assembler
	to generate this warning -- isn't it in general the linker's
	job to check that relative relocations are within range?

	It appears that the assembler compares "0" (value without
	patched-up relocation?) as the target of the offset when
	emitting the error message.


>How-To-Repeat:
	Try to compile a vax kernel with version 1.3 of intvec.S
	with new binutils installed.  Watch it fail with above error
	message.


>Fix:
	Don't know, out of my leage.  Workaround by using "brw" for
	the moment will be committed shortly.
>Release-Note:
>Audit-Trail:

From: Havard Eidnes <he@netbsd.org>
To: gnats-bugs@gnats.netbsd.org
Cc:  
Subject: pr/20924 CVS commit: src/sys/arch/vax/vax
Date: Fri, 28 Mar 2003 22:25:41 +0200 (EET)

 Module Name:	src
 Committed By:	he
 Date:		Fri Mar 28 20:25:41 UTC 2003

 Modified Files:
 	src/sys/arch/vax/vax: intvec.S

 Log Message:
 Commit a workaround for PR toolchain/20924, so that this compiles again.
 When/if the PR is fixed, this change should probably be reverted.


 To generate a diff of this commit:
 cvs rdiff -r1.4 -r1.5 src/sys/arch/vax/vax/intvec.S

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.


From: Havard Eidnes <he@netbsd.org>
To: gnats-bugs@gnats.netbsd.org
Cc:  
Subject: pr/20924 CVS commit: src/doc
Date: Fri, 28 Mar 2003 23:15:20 +0200 (EET)

 Module Name:	src
 Committed By:	he
 Date:		Fri Mar 28 21:15:20 UTC 2003

 Modified Files:
 	src/doc: HACKS

 Log Message:
 Document hack/workaround for PR toolchain/20924.


 To generate a diff of this commit:
 cvs rdiff -r1.1 -r1.2 src/doc/HACKS

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

Responsible-Changed-From-To: toolchain-manager->matt 
Responsible-Changed-By: perry 
Responsible-Changed-When: Sat Mar 29 08:53:01 PST 2003 
Responsible-Changed-Why:  
Matt Thomas knows the vax toolchain better than anyone else. 
State-Changed-From-To: open->feedback
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Sun, 13 Feb 2011 05:14:02 +0000
State-Changed-Why:
Is the workaround still needed these days? I don't have a vax toolchain on
hand but I'm sure someone does and it's easy to test it...


From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@NetBSD.org
Cc: matt@NetBSD.org, netbsd-bugs@netbsd.org, gnats-admin@netbsd.org,
	dholland@NetBSD.org, he@netbsd.org
Subject: Re: toolchain/20924 (vax assembler checking for byte offsets causes build error)
Date: Sun, 13 Feb 2011 11:18:12 +0100

 On Sun, Feb 13, 2011 at 05:14:05AM +0000, dholland@NetBSD.org wrote:
 > Is the workaround still needed these days? I don't have a vax toolchain on
 > hand but I'm sure someone does and it's easy to test it...

 This is -current with the workaround removed:

 ../../../../arch/vax/vax/intvec.S:244: Error: value of -721 too large for field of 1 bytes at 720


 Martin

From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: toolchain/20924 (vax assembler checking for byte offsets causes
 build error)
Date: Sun, 13 Feb 2011 20:46:52 +0000

 On Sun, Feb 13, 2011 at 10:20:04AM +0000, Martin Husemann wrote:
  >  This is -current with the workaround removed:
  >  
  >  ../../../../arch/vax/vax/intvec.S:244: Error: value of -721 too large for field of 1 bytes at 720

 Matt says it isn't a bug for the assembler to do this, so I guess the
 way forward is to remove the entry from src/doc/HACKS and close the
 PR. Anyone object?

 -- 
 David A. Holland
 dholland@netbsd.org

From: christos@zoulas.com (Christos Zoulas)
To: gnats-bugs@NetBSD.org, matt@NetBSD.org, gnats-admin@netbsd.org, 
	netbsd-bugs@netbsd.org, he@netbsd.org
Cc: 
Subject: Re: toolchain/20924 (vax assembler checking for byte offsets causes build error)
Date: Sun, 13 Feb 2011 16:11:43 -0500

 On Feb 13,  8:50pm, dholland-bugs@netbsd.org (David Holland) wrote:
 -- Subject: Re: toolchain/20924 (vax assembler checking for byte offsets caus

 | The following reply was made to PR toolchain/20924; it has been noted by GNATS.
 | 
 | From: David Holland <dholland-bugs@netbsd.org>
 | To: gnats-bugs@NetBSD.org
 | Cc: 
 | Subject: Re: toolchain/20924 (vax assembler checking for byte offsets causes
 |  build error)
 | Date: Sun, 13 Feb 2011 20:46:52 +0000
 | 
 |  On Sun, Feb 13, 2011 at 10:20:04AM +0000, Martin Husemann wrote:
 |   >  This is -current with the workaround removed:
 |   >  
 |   >  ../../../../arch/vax/vax/intvec.S:244: Error: value of -721 too large for field of 1 bytes at 720
 |  
 |  Matt says it isn't a bug for the assembler to do this, so I guess the
 |  way forward is to remove the entry from src/doc/HACKS and close the
 |  PR. Anyone object?

 I agree, but I also think that the error message could be better.

 christos

From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: toolchain/20924 (vax assembler checking for byte offsets causes
 build error)
Date: Sun, 13 Feb 2011 22:11:08 +0000

 On Sun, Feb 13, 2011 at 09:15:05PM +0000, Christos Zoulas wrote:
  >  |  Matt says it isn't a bug for the assembler to do this, so I guess the
  >  |  way forward is to remove the entry from src/doc/HACKS and close the
  >  |  PR. Anyone object?
  >  
  >  I agree, but I also think that the error message could be better.

 It's at line 1053 of src/external/gpl3/binutils/dist/gas/write.c if
 someone wants to tinker with it.

 -- 
 David A. Holland
 dholland@netbsd.org

From: "Havard Eidnes" <he@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/20924 CVS commit: src/doc
Date: Thu, 20 Oct 2016 07:33:28 +0000

 Module Name:	src
 Committed By:	he
 Date:		Thu Oct 20 07:33:28 UTC 2016

 Modified Files:
 	src/doc: HACKS

 Log Message:
 Per the discussion in PR#20924, remove the HACK entry for intvec.S on vax.


 To generate a diff of this commit:
 cvs rdiff -u -r1.174 -r1.175 src/doc/HACKS

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

State-Changed-From-To: feedback->closed
State-Changed-By: he@NetBSD.org
State-Changed-When: Thu, 20 Oct 2016 07:39:46 +0000
State-Changed-Why:
It's time to close this PR.
The fix to intvec.S is deemed to be the right way to deal with this.
The error message from gas is the same as it was.


>Unformatted:

Home	PR Database Search