NetBSD Problem Report #51238

From www@NetBSD.org  Mon Jun 13 15:39:15 2016
Return-Path: <www@NetBSD.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.netbsd.org", Issuer "Postmaster NetBSD.org" (verified OK))
	by mollari.NetBSD.org (Postfix) with ESMTPS id EB83A7A20F
	for <gnats-bugs@gnats.NetBSD.org>; Mon, 13 Jun 2016 15:39:14 +0000 (UTC)
Message-Id: <20160613153914.084137A478@mollari.NetBSD.org>
Date: Mon, 13 Jun 2016 15:39:14 +0000 (UTC)
From: nolden@kde.org
Reply-To: nolden@kde.org
To: gnats-bugs@NetBSD.org
Subject: ELF binaries don't carry ELFOSABI_NETBSD in their header
X-Send-Pr-Version: www-1.0

>Number:         51238
>Category:       toolchain
>Synopsis:       ELF binaries don't carry ELFOSABI_NETBSD in their header
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    toolchain-manager
>State:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Mon Jun 13 15:40:00 +0000 2016
>Last-Modified:  Fri Jun 17 16:25:00 +0000 2016
>Originator:     Ralf Nolden
>Release:        7.0
>Organization:
KDE
>Environment:
NetBSD 7.0 amd64
>Description:
According to http://netbsd.gw.com/cgi-bin/man-cgi?elf+5 the
ELFOSABI_NETBSD is defined but not used:

EI_OSABI       Contains the operating system ABI identifica-
                                 tion. Note that even though the definition
                                 ELFOSABI_NETBSD exists, NetBSD uses
                                 ELFOSABI_SYSV here, since the NetBSD ABI does
                                 not deviate from the standard.

However, a lot of binary programs that inspect elf binaries use the header instead of inspecting PT_NOTE. Unfortunately, those programs will detect NetBSD binaries as UNIX binaries and depending on their logic will use some default value like Linux as the OS the binary is built for, such as Qt Creator.

It should be considered using the define, even if NetBSD isn't deviate from the standard. The binary information in the header serves the purpose to find out on which platform the binary was built.
>How-To-Repeat:
readelf -h /usr/bin/info
>Fix:

>Audit-Trail:
From: Joerg Sonnenberger <joerg@bec.de>
To: gnats-bugs@NetBSD.org
Cc: toolchain-manager@netbsd.org, gnats-admin@netbsd.org,
	netbsd-bugs@netbsd.org
Subject: Re: toolchain/51238: ELF binaries don't carry ELFOSABI_NETBSD in
 their header
Date: Mon, 13 Jun 2016 22:56:53 +0200

 On Mon, Jun 13, 2016 at 03:40:00PM +0000, nolden@kde.org wrote:
 > >Description:
 > According to http://netbsd.gw.com/cgi-bin/man-cgi?elf+5 the
 > ELFOSABI_NETBSD is defined but not used:

 This is intentional.

 > However, a lot of binary programs that inspect elf binaries use the
 > header instead of inspecting PT_NOTE. Unfortunately, those programs
 > will detect NetBSD binaries as UNIX binaries and depending on their
 > logic will use some default value like Linux as the OS the binary is
 > built for, such as Qt Creator.

 That's a bug in the programs. There is no advantage to tagging with
 ELFOSABI_NETBSD. AS such: "No bug here, works as intended"

 Joerg

From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: toolchain/51238: ELF binaries don't carry ELFOSABI_NETBSD in
 their header
Date: Tue, 14 Jun 2016 07:10:35 +0000

 On Mon, Jun 13, 2016 at 09:00:02PM +0000, Joerg Sonnenberger wrote:
  >  > According to http://netbsd.gw.com/cgi-bin/man-cgi?elf+5 the
  >  > ELFOSABI_NETBSD is defined but not used:
  >  
  >  This is intentional.
  >  
  >  > However, a lot of binary programs that inspect elf binaries use the
  >  > header instead of inspecting PT_NOTE. Unfortunately, those programs
  >  > will detect NetBSD binaries as UNIX binaries and depending on their
  >  > logic will use some default value like Linux as the OS the binary is
  >  > built for, such as Qt Creator.
  >  
  >  That's a bug in the programs. There is no advantage to tagging with
  >  ELFOSABI_NETBSD. AS such: "No bug here, works as intended"

 ...other than say tagging the binary with the correct OS.

 Last I checked we don't have the same syscall table as SVR4, except
 when compat_svr4 is in use, so we hardly have the same OS ABI.

 -- 
 David A. Holland
 dholland@netbsd.org

From: Joerg Sonnenberger <joerg@bec.de>
To: gnats-bugs@NetBSD.org
Cc: toolchain-manager@netbsd.org, gnats-admin@netbsd.org,
	netbsd-bugs@netbsd.org, nolden@kde.org
Subject: Re: toolchain/51238: ELF binaries don't carry ELFOSABI_NETBSD in
 their header
Date: Tue, 14 Jun 2016 10:18:20 +0200

 On Tue, Jun 14, 2016 at 07:15:01AM +0000, David Holland wrote:
 > The following reply was made to PR toolchain/51238; it has been noted by GNATS.
 > 
 > From: David Holland <dholland-bugs@netbsd.org>
 > To: gnats-bugs@NetBSD.org
 > Cc: 
 > Subject: Re: toolchain/51238: ELF binaries don't carry ELFOSABI_NETBSD in
 >  their header
 > Date: Tue, 14 Jun 2016 07:10:35 +0000
 > 
 >  On Mon, Jun 13, 2016 at 09:00:02PM +0000, Joerg Sonnenberger wrote:
 >   >  > According to http://netbsd.gw.com/cgi-bin/man-cgi?elf+5 the
 >   >  > ELFOSABI_NETBSD is defined but not used:
 >   >  
 >   >  This is intentional.
 >   >  
 >   >  > However, a lot of binary programs that inspect elf binaries use the
 >   >  > header instead of inspecting PT_NOTE. Unfortunately, those programs
 >   >  > will detect NetBSD binaries as UNIX binaries and depending on their
 >   >  > logic will use some default value like Linux as the OS the binary is
 >   >  > built for, such as Qt Creator.
 >   >  
 >   >  That's a bug in the programs. There is no advantage to tagging with
 >   >  ELFOSABI_NETBSD. AS such: "No bug here, works as intended"
 >  
 >  ...other than say tagging the binary with the correct OS.
 >  
 >  Last I checked we don't have the same syscall table as SVR4, except
 >  when compat_svr4 is in use, so we hardly have the same OS ABI.

 It is not about system calls. It is about the implemented ABI. That's
 what we follow, including stack alignment on i386 etc. Looking at
 FreeBSD, they had more than enough problems with requiring tagging with
 the OSABI. It is a crude and limited hack. Heck, if you don't want to
 parse PT_NOTE yourself, call file(1).

 Joerg

From: christos@zoulas.com (Christos Zoulas)
To: gnats-bugs@NetBSD.org, toolchain-manager@netbsd.org, 
	gnats-admin@netbsd.org, netbsd-bugs@netbsd.org, nolden@kde.org
Cc: 
Subject: Re: toolchain/51238: ELF binaries don't carry ELFOSABI_NETBSD in their header
Date: Tue, 14 Jun 2016 07:13:32 -0400

 On Jun 14,  7:15am, dholland-bugs@netbsd.org (David Holland) wrote:
 -- Subject: Re: toolchain/51238: ELF binaries don't carry ELFOSABI_NETBSD in 

 |  ...other than say tagging the binary with the correct OS.
 |  
 |  Last I checked we don't have the same syscall table as SVR4, except
 |  when compat_svr4 is in use, so we hardly have the same OS ABI.

 0 (SYSV) means "No extensions or Unspecified"

     http://www.sco.com/developers/gabi/2003-12-17/ch4.eheader.html

 christos

From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: toolchain/51238: ELF binaries don't carry ELFOSABI_NETBSD in
 their header
Date: Fri, 17 Jun 2016 15:47:21 +0000

 On Tue, Jun 14, 2016 at 08:20:01AM +0000, Joerg Sonnenberger wrote:
  >  >  Last I checked we don't have the same syscall table as SVR4, except
  >  >  when compat_svr4 is in use, so we hardly have the same OS ABI.
  >  
  >  It is not about system calls. It is about the implemented ABI. That's
  >  what we follow, including stack alignment on i386 etc. Looking at
  >  FreeBSD, they had more than enough problems with requiring tagging with
  >  the OSABI. It is a crude and limited hack. Heck, if you don't want to
  >  parse PT_NOTE yourself, call file(1).

 So the "OS ABI" is not the OS ABI, but something akin to the ELF
 version?

 I suppose I shouldn't be surprised about ELF doing things wrong.

 -- 
 David A. Holland
 dholland@netbsd.org

From: Joerg Sonnenberger <joerg@bec.de>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: toolchain/51238: ELF binaries don't carry ELFOSABI_NETBSD in
 their header
Date: Fri, 17 Jun 2016 18:23:18 +0200

 On Fri, Jun 17, 2016 at 03:50:00PM +0000, David Holland wrote:
 > The following reply was made to PR toolchain/51238; it has been noted by GNATS.
 > 
 > From: David Holland <dholland-bugs@netbsd.org>
 > To: gnats-bugs@NetBSD.org
 > Cc: 
 > Subject: Re: toolchain/51238: ELF binaries don't carry ELFOSABI_NETBSD in
 >  their header
 > Date: Fri, 17 Jun 2016 15:47:21 +0000
 > 
 >  On Tue, Jun 14, 2016 at 08:20:01AM +0000, Joerg Sonnenberger wrote:
 >   >  >  Last I checked we don't have the same syscall table as SVR4, except
 >   >  >  when compat_svr4 is in use, so we hardly have the same OS ABI.
 >   >  
 >   >  It is not about system calls. It is about the implemented ABI. That's
 >   >  what we follow, including stack alignment on i386 etc. Looking at
 >   >  FreeBSD, they had more than enough problems with requiring tagging with
 >   >  the OSABI. It is a crude and limited hack. Heck, if you don't want to
 >   >  parse PT_NOTE yourself, call file(1).
 >  
 >  So the "OS ABI" is not the OS ABI, but something akin to the ELF
 >  version?

 Not exactly the ELF version, but it is essentially a marker for "I am
 using OS specific extensions to the normal platform rules". E.g. we
 should be marking the binaries if we introduce custom relocations. I
 don't think the TLS relocations for example qualify as they have all
 been submitted for allocation in the appropiate platform ABI
 supplementals.

 Joerg

Home	PR Database Search