NetBSD Problem Report #46715

From www@NetBSD.org  Tue Jul 17 15:59:36 2012
Return-Path: <www@NetBSD.org>
Received: from mail.netbsd.org (mail.netbsd.org [149.20.53.66])
	by www.NetBSD.org (Postfix) with ESMTP id C8E5963BA6C
	for <gnats-bugs@gnats.NetBSD.org>; Tue, 17 Jul 2012 15:59:36 +0000 (UTC)
Message-Id: <20120717155935.495B463B882@www.NetBSD.org>
Date: Tue, 17 Jul 2012 15:59:35 +0000 (UTC)
From: paulkoning@comcast.net
Reply-To: paulkoning@comcast.net
To: gnats-bugs@NetBSD.org
Subject: Relocation in .text section in vax does not work
X-Send-Pr-Version: www-1.0

>Number:         46715
>Category:       port-vax
>Synopsis:       Relocation in .text section in vax does not work
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    port-vax-maintainer
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Jul 17 16:00:00 +0000 2012
>Closed-Date:    Sat Mar 05 09:21:32 +0000 2016
>Last-Modified:  Sat Mar 05 09:21:32 +0000 2016
>Originator:     Paul Koning
>Release:        5.1
>Organization:
>Environment:
NetBSD pk3900 5.1 NetBSD 5.1 (GENERIC) #0: Thu Jul 12 21:33:26 EDT 2012  pkoning@plato4.lab.equallogic.com:/buildarea/objdir.vax/buildarea/netbsd-51/src/sys/arch/vax/compile/GENERIC vax

>Description:
I ran into this problem trying to build gmp 5.0.5 on netbsd/vax.  There are some assembly language files that are linked into a shared library; those contain code like this:

   jmp   Loop(%r5)

(to jump into the middle of an unrolled loop).  So that assembles into a reference to label Loop, which is relocatable.  

The compiler is happy; the linker warns:  "Warning: R_VAX_32 relocation to 0xnnnn from .text section".  At runtime, I get a segfault in ld.elf_so at the point where it tries to apply that relocation; apparently it didn't flip the segment to be writable at this point as most other ld.elf_so ports do.

This particular bit of code is not hard to change for a workaround:

   jmp    Loop[%r5]

but that requires a source level fix and in other cases it might not be so easy.
>How-To-Repeat:
Here's a simple test program bug.s:

# This shows an ld.elf_so bug

        .text

        .globl  foo
foo:
        .word   0
        clrl    %r0
        jmp     bug(%r0)
bug:
        ret

Assemble (gcc -c bug.s) then link (ld --shared -o libbug.so bug.o).  The link step shows the warning I mentioned.

Link another file with this shared library, for example:


extern void foo(void);

int main (int c, char **v)
{
    foo ();
    return 0;
}

gcc bugmain.c -lbug -L .
./a.out

will show the segfault.
>Fix:

>Release-Note:

>Audit-Trail:
From: christos@zoulas.com (Christos Zoulas)
To: gnats-bugs@NetBSD.org, port-vax-maintainer@netbsd.org, 
	gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Cc: 
Subject: Re: port-vax/46715: Relocation in .text section in vax does not work
Date: Tue, 17 Jul 2012 14:22:53 -0400

 On Jul 17,  4:00pm, paulkoning@comcast.net (paulkoning@comcast.net) wrote:
 -- Subject: port-vax/46715: Relocation in .text section in vax does not work

 The bug could be in many places, but not in ld.elf_so:
 1. If the source is compiled with -fPIC or -fpic, then it should not emit
    R_VAX_32; if it does then it is an assembler bug.
 2. If the source is not compiled with -fPIC or -fpic, then it is ok to
    emit R_VAX_32, but but then the linker should mark the object with
    DT_TEXTREL so that the rtld knows to mmap the text writable before
    doing relocations.

 Can you investigate who is at fault? The package for not passing -f{PIC,pic}?
 The assembler/linker? Both?

 christos

From: <Paul_Koning@Dell.com>
To: <christos@zoulas.com>
Cc: <gnats-bugs@NetBSD.org>, <port-vax-maintainer@netbsd.org>,
	<gnats-admin@netbsd.org>, <netbsd-bugs@netbsd.org>
Subject: Re: port-vax/46715: Relocation in .text section in vax does not work
Date: Tue, 17 Jul 2012 18:37:48 +0000

 On Jul 17, 2012, at 2:22 PM, Christos Zoulas wrote:

 > On Jul 17,  4:00pm, paulkoning@comcast.net (paulkoning@comcast.net) wrote=
 :
 > -- Subject: port-vax/46715: Relocation in .text section in vax does not w=
 ork
 >=20
 > The bug could be in many places, but not in ld.elf_so:
 > 1. If the source is compiled with -fPIC or -fpic, then it should not emit
 >   R_VAX_32; if it does then it is an assembler bug.

 In the sample program (bug.s) I supplied, the code as written is clearly no=
 t PIC.  And when assembling it, I didn't say -fpic or -fPIC, so I told the =
 tool correctly.

 > 2. If the source is not compiled with -fPIC or -fpic, then it is ok to
 >   emit R_VAX_32, but but then the linker should mark the object with
 >   DT_TEXTREL so that the rtld knows to mmap the text writable before
 >   doing relocations.

 Where would I look for a DT_TEXTREL marking?  objdump -R shows just a singl=
 e entry, which is the one that is causing things to blow up.

 > Can you investigate who is at fault? The package for not passing -f{PIC,p=
 ic}?
 > The assembler/linker? Both?

 Sounds like the linker.  For one thing, if it can give instructions to the =
 loader on how to do the right thing, it should do so without spitting out c=
 onfusing warnings.

 ld is the one that comes stock with 5.1 -- "version 2.16.1 20051220".

 	paul

From: christos@zoulas.com (Christos Zoulas)
To: gnats-bugs@NetBSD.org, port-vax-maintainer@netbsd.org, 
	gnats-admin@netbsd.org, netbsd-bugs@netbsd.org, paulkoning@comcast.net
Cc: 
Subject: Re: port-vax/46715: Relocation in .text section in vax does not work
Date: Wed, 18 Jul 2012 16:14:33 -0400

 On Jul 17,  6:40pm, Paul_Koning@Dell.com (<Paul_Koning@Dell.com>) wrote:
 -- Subject: Re: port-vax/46715: Relocation in .text section in vax does not w

 |  Sounds like the linker.  For one thing, if it can give instructions to the =
 |  loader on how to do the right thing, it should do so without spitting out c=
 |  onfusing warnings.
 |  
 |  ld is the one that comes stock with 5.1 -- "version 2.16.1 20051220".

 Matt Thomas fixed both the assembler and the linker on head.

 christos

State-Changed-From-To: open->closed
State-Changed-By: ragge@NetBSD.org
State-Changed-When: Sat, 05 Mar 2016 09:21:32 +0000
State-Changed-Why:
Bug was fixed in toolchain by Matt Thomas.


>Unformatted:

Home	PR Database Search