NetBSD Problem Report #44848

From mrg@eterna.com.au  Sun Apr 10 08:44:08 2011
Return-Path: <mrg@eterna.com.au>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
	by www.NetBSD.org (Postfix) with ESMTP id C46CE63C287
	for <gnats-bugs@gnats.NetBSD.org>; Sun, 10 Apr 2011 08:44:08 +0000 (UTC)
Message-Id: <20110410084348.3DA7937534@splode.eterna.com.au>
Date: Sun, 10 Apr 2011 18:43:48 +1000 (EST)
From: mrg@eterna.com.au
Reply-To: mrg@eterna.com.au
To: gnats-bugs@gnats.NetBSD.org
Subject: ideas for enhancing the toolchain tests
X-Send-Pr-Version: 3.95

>Number:         44848
>Category:       toolchain
>Synopsis:       ideas for enhancing the toolchain tests
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    toolchain-manager
>State:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Sun Apr 10 08:45:00 +0000 2011
>Last-Modified:  Tue Apr 12 09:05:01 +0000 2011
>Originator:     matthew green
>Release:        NetBSD -current
>Organization:
people's front against (bozotic) www (softwar foundation)
>Environment:
>Description:

	the hello32 test is always installed and run on systems that may
	support "cc -m32" args, but not have installed libs (MKCOMAPT=no.)

	martin and i discussed splitting it up into a separate case that
	can be installed or not based upon make variables, which would allow
	non-bogus failures for these systems.  we also discusssed a few other
	ideas, and he asked me to file this PR with info.

	in these lists, "MLIBDIR" is the /usr/lib/$MLIBDIR the compat libs
	are installed into.

	for amd64 we have:
		MLIBDIR=                i386
		LD+=                    -m elf_i386
		COPTS+=                 -m32
		CPUFLAGS+=              -m32
		LDADD+=                 -m32
		LDFLAGS+=               -m32
		MKDEPFLAGS+=            -m32

	for sparc64 we have:
		MLIBDIR=                sparc
		LD+=                    -m elf32_sparc
		COPTS+=                 -m32
		CPUFLAGS+=              -m32
		LDADD+=                 -m32
		LDFLAGS+=               -m32
		MKDEPFLAGS+=            -m32

	for mips64/64 we have:
		MLIBDIR=        64
	    for BE:
		LD+=            -m elf64btsmip
	    for LE:
		LD+=            -m elf64ltsmip
		COPTS+=         -mabi=64
		CPUFLAGS+=      -mabi=64
		LDADD+=         -mabi=64
		LDFLAGS+=       -mabi=64
		MKDEPFLAGS+=    -mabi=64

	for mips64/o32 we have:
		MLIBDIR=        o32
	    for BE:
		LD+=            -m elf32btsmip
	    for LE:
		LD+=            -m elf32ltsmip
		COPTS+=         -mabi=32 -march=mips3
		CPUFLAGS+=      -mabi=32 -march=mips3
		LDADD+=         -mabi=32 -march=mips3
		LDFLAGS+=       -mabi=32 -march=mips3
		MKDEPFLAGS+=    -mabi=32 -march=mips3

	(for reference, this data is currently located in
	src/compat/$MACHINE/*/bsd.*.mk and src/compat/m32.mk.)

>How-To-Repeat:
>Fix:

>Audit-Trail:
From: Jukka Ruohonen <jruohonen@iki.fi>
To: gnats-bugs@NetBSD.org
Cc: martin@NetBSD.org
Subject: Re: toolchain/44848: ideas for enhancing the toolchain tests
Date: Tue, 12 Apr 2011 09:14:27 +0300

 On Sun, Apr 10, 2011 at 08:45:01AM +0000, mrg@eterna.com.au wrote:
 > 	martin and i discussed splitting it up into a separate case that
 > 	can be installed or not based upon make variables, which would allow
 > 	non-bogus failures for these systems.  we also discusssed a few other
 > 	ideas, and he asked me to file this PR with info.

 Tangential to this, what would be the preferred way to test general toolchain
 issues? Things like the one below are often seen in HEAD. It would be good
 to have same consistent and easy way to pick these already from the automated
 test runs.

 	"programs compiles with -pthread and -pg segfault"

 	http://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=39537

 	(As an example; not sure if this particular case is still relevant.)

From: matthew green <mrg@eterna.com.au>
To: gnats-bugs@NetBSD.org
Cc: toolchain-manager@netbsd.org, gnats-admin@netbsd.org,
    netbsd-bugs@netbsd.org
Subject: re: toolchain/44848: ideas for enhancing the toolchain tests
Date: Tue, 12 Apr 2011 16:45:24 +1000

 >  Tangential to this, what would be the preferred way to test general toolchain
 >  issues? Things like the one below are often seen in HEAD. It would be good
 >  to have same consistent and easy way to pick these already from the automated
 >  test runs.
 >  
 >  	"programs compiles with -pthread and -pg segfault"
 >  
 >  	http://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=39537
 >  
 >  	(As an example; not sure if this particular case is still relevant.)

 i'm not sure that these need to be toolchain specific?  ie, just a
 test that (if MKPROFILE != no) compiles something -pthread -pg and
 then tries to run it (just a hello would be fine.)  for multiple
 cases, perhaps a series of flags and a hello.c?

 ... or am i missing what you mean?

 (a much larger issue, IMO, would be getting the gcc testsuite
 itself run here some how...but i'm not sure how to do that..)


 .mrg.

From: Jukka Ruohonen <jruohonen@iki.fi>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: toolchain/44848: ideas for enhancing the toolchain tests
Date: Tue, 12 Apr 2011 09:54:16 +0300

 On Tue, Apr 12, 2011 at 06:50:04AM +0000, matthew green wrote:
 >  then tries to run it (just a hello would be fine.)  for multiple
 >  cases, perhaps a series of flags and a hello.c?
 >  
 >  ... or am i missing what you mean?

 This was indeed my point; compile "hello world" (or something more involved)
 with various different compiler and/or linker flags on a given architecture.

 - Jukka.

From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@NetBSD.org
Cc: mrg@eterna.com.au
Subject: Re: toolchain/44848: ideas for enhancing the toolchain tests
Date: Tue, 12 Apr 2011 11:03:22 +0200

 On Tue, Apr 12, 2011 at 06:55:03AM +0000, Jukka Ruohonen wrote:
 >  This was indeed my point; compile "hello world" (or something more involved)
 >  with various different compiler and/or linker flags on a given architecture.

 There are two parts to this:

 We should create a set of various "hello world" test binaries (where
 various includes the flags you mentioned and arch dependend also -m32
 resp. the -mabi= variations Matt mentioned).

 Then we should test runability of all those pre-compiled test binaries,
 exit status and output (trivial).

 This should be done and requires a kind of hardcoded matrix for the special
 arch dependend options (as we can't play the games the current hello32 test
 does at runtime).

 Another thing is to test exactly the same options matrix, but compile
 at test time, verify binaries are of proper type (i.e. by comparing
 file(1) and/or objdump output with the pregenerated test binaries from
 above), and then (of course) do the same execution tests as above for
 the freshly created binaries.

 Martin

Home	PR Database Search