From isupov@moonhe.jinr.ru  Fri Jan 18 10:12:37 2008
Return-Path: <isupov@moonhe.jinr.ru>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id D95FB16A418
	for <FreeBSD-gnats-submit@freebsd.org>; Fri, 18 Jan 2008 10:12:37 +0000 (UTC)
	(envelope-from isupov@moonhe.jinr.ru)
Received: from moonhe.jinr.ru (moonhe.jinr.ru [159.93.113.11])
	by mx1.freebsd.org (Postfix) with ESMTP id D9FCE13C46B
	for <FreeBSD-gnats-submit@freebsd.org>; Fri, 18 Jan 2008 10:12:36 +0000 (UTC)
	(envelope-from isupov@moonhe.jinr.ru)
Received: from moonhe.jinr.ru (isupov@localhost [127.0.0.1])
	by moonhe.jinr.ru (8.13.4/8.13.4) with ESMTP id m0I9mUd6070471
	for <FreeBSD-gnats-submit@freebsd.org>; Fri, 18 Jan 2008 12:48:30 +0300 (MSK)
	(envelope-from isupov@moonhe.jinr.ru)
Received: (from isupov@localhost)
	by moonhe.jinr.ru (8.13.4/8.13.4/Submit) id m0I9mUS2070470;
	Fri, 18 Jan 2008 12:48:30 +0300 (MSK)
	(envelope-from isupov)
Message-Id: <200801180948.m0I9mUS2070470@moonhe.jinr.ru>
Date: Fri, 18 Jan 2008 12:48:30 +0300 (MSK)
From: "Isupov A.Yu." <isupov@moonhe.jinr.ru>
Reply-To: "Isupov A.Yu." <isupov@moonhe.jinr.ru>
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: troubles w/ -m32 executables on both amd64 and i386
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         119771
>Category:       amd64
>Synopsis:       troubles w/ -m32 executables on both amd64 and i386
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-amd64
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Fri Jan 18 10:20:01 UTC 2008
>Closed-Date:    Mon Jan 21 15:02:33 UTC 2008
>Last-Modified:  Mon Jan 21 15:02:33 UTC 2008
>Originator:     Isupov A.Yu.
>Release:        FreeBSD 6.2-RELEASE amd64
>Organization:
LHE, JINR
>Environment:
	Binaries produced under:
	(uname -a)
FreeBSD tempor.jinr.ru 6.2-RELEASE FreeBSD 6.2-RELEASE #0: Thu Jan  3 21:11:58
MSK 2008     isupov@tempor.jinr.ru:/usr/src/sys/amd64/compile/MOONHE  amd64

	with three library sets:
	/usr/lib32 -	1) originally distributed w/ amd64 6.2-RELEASE
			2) distributed w/ i386 6.2-RELEASE as /usr/lib
			3) distributed w/ i386 6.0-RELEASE as /usr/lib

	Binaries executed under:
	1)
FreeBSD tempor.jinr.ru 6.2-RELEASE FreeBSD 6.2-RELEASE #0: Thu Jan  3 21:11:58
MSK 2008     isupov@tempor.jinr.ru:/usr/src/sys/amd64/compile/TEMPOR  amd64

	2)
FreeBSD tempor.jinr.ru 6.2-RELEASE FreeBSD 6.2-RELEASE #1: Sat Jan  5 19:01:25
MSK 2008     isupov@tempor.jinr.ru:/usr/src/sys/i386/compile/TEMPOR  i386

	3)
FreeBSD moonhe.jinr.ru 6.0-RELEASE FreeBSD 6.0-RELEASE #2: Thu Oct  5 10:23:22
MSD 2006     isupov@moonhe.jinr.ru:/usr/sys/i386/compile/MOONHE  i386

	amd64 and i386 6.2-RELEASE: Athlon64 X2 5600+ based
		m/b ECS C51PVGM-M Socket AM2 (nVIDIA C51PVG+MCP51/G) mkATX
	i386 6.0-RELEASE: Athlon XP 2500+ based
		m/b Abit KX7-333R SocketA (VIA KT333) ATX

>Description:

	Code mentioned in How-To-Repeat: obtains SIGSEGV:
6.0-RELEASE i386> ./ddd
f=0
cur=-1 max=2.14748e+09
Segmentation fault (core dumped)

	due to stack frames damage, as we can see:

6.0-RELEASE i386> gdb ./ddd ddd.core
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-marcel-freebsd"...
Core was generated by `ddd'.
Program terminated with signal 11, Segmentation fault.
#0  0x7fffffff in ?? ()
(gdb) bt
#0  0x7fffffff in ?? ()
#1  0xbfbfdeb4 in ?? ()
#2  0x00000000 in ?? ()
#3  0x00000000 in ?? ()
#4  0x00000001 in ?? ()
#5  0xbfbfdf10 in ?? ()
#6  0x00000000 in ?? ()
#7  0xbfbfdec8 in ?? ()
#8  0x080515b5 in atexit ()
Cannot access memory at address 0x3
(gdb) q

	Step-by-steping under debugger shows, that SIGSEGV generated during return
	from bbb() to main(), while really stack frames damaged after
	return from getrlimit(2):

6.0-RELEASE i386> gdb ./ddd 
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-marcel-freebsd"...
(gdb) break main
Breakpoint 1 at 0x804825c: file ddd.c, line 41.
(gdb) run
Starting program: /home/users/alis/misc/F/F+C/ddd 

Breakpoint 1, main () at ddd.c:41
41              float f=0.0;
(gdb) step
43              printf("f=%g\n", f);
(gdb) 
f=0
44              bbb(&f);
(gdb) 
bbb (f=0xbfbfde84) at ddd.c:18
18              if (!flag)
(gdb) 
21              if (!getrlimit(RLIMIT_CPU, &rlim)) {
(gdb) info frame 0
Stack frame at 0xbfbfde60:
 eip = 0x80481d1 in bbb (ddd.c:21); saved eip 0x8048282
 called by frame at 0xbfbfde90
 source language c.
 Arglist at 0xbfbfde58, args: f=0xbfbfde84
 Locals at 0xbfbfde58, Previous frame's sp is 0xbfbfde60
 Saved registers:
  ebp at 0xbfbfde58, eip at 0xbfbfde5c
(gdb) info frame 1
Stack frame at 0xbfbfde90:
 eip = 0x8048282 in main (ddd.c:44); saved eip 0x8048106
 caller of frame at 0xbfbfde60
 source language c.
 Arglist at 0xbfbfde88, args: 
 Locals at 0xbfbfde88, Previous frame's sp is 0xbfbfde90
 Saved registers:
  ebp at 0xbfbfde88, eip at 0xbfbfde8c
(gdb) step
22                      printf("cur=%g max=%g\n",
(gdb) info frame 0
Stack frame at 0xbfbfde60:
 eip = 0x80481e8 in bbb (ddd.c:22); saved eip 0x7fffffff
 called by frame at 0xbfbfde64
 source language c.
 Arglist at 0xbfbfde58, args: f=0xbfbfde84
 Locals at 0xbfbfde58, Previous frame's sp is 0xbfbfde60
 Saved registers:
  ebp at 0xbfbfde58, eip at 0xbfbfde5c
(gdb) info frame 1
Stack frame at 0xbfbfde64:
 eip = 0x7fffffff; saved eip 0xbfbfde84
 called by frame at 0xbfbfde68, caller of frame at 0xbfbfde60
 Arglist at 0xbfbfde5c, args: 
 Locals at 0xbfbfde5c, Previous frame's sp is 0xbfbfde64
 Saved registers:
  ebp at 0xbfbfde58, eip at 0xbfbfde60
(gdb) info frame 2
Stack frame at 0xbfbfde68:
 eip = 0xbfbfde84; saved eip 0x0
 called by frame at 0xbfbfde6c, caller of frame at 0xbfbfde64
 Arglist at 0xbfbfde60, args: 
 Locals at 0xbfbfde60, Previous frame's sp is 0xbfbfde68
 Saved registers:
  ebp at 0xbfbfde58, eip at 0xbfbfde64
(gdb) info frame 3
Stack frame at 0xbfbfde6c:
 eip = 0x0; saved eip 0x0
 called by frame at 0xbfbfde70, caller of frame at 0xbfbfde68
 Arglist at 0xbfbfde64, args: 
 Locals at 0xbfbfde64, Previous frame's sp is 0xbfbfde6c
 Saved registers:
  ebp at 0xbfbfde58, eip at 0xbfbfde68
(gdb) step
cur=-1 max=2.14748e+09
25                      if (rlim.rlim_cur != RLIM_INFINITY)
(gdb) 
28                              *f = (float)rlim.rlim_max;
(gdb) 
36              flag = 0;
(gdb) 
37      }
(gdb) 

Program received signal SIGSEGV, Segmentation fault.
0x7fffffff in ?? ()
(gdb) c
Continuing.

Program terminated with signal SIGSEGV, Segmentation fault.
The program no longer exists.
(gdb) q

	Some another syscalls, for example getpid(2) or getpriority(2),
	does not produce such effect.

	Picture under i386 and amd64 6.2-RELEASE very similar:

6.2-RELEASE amd64> ./ddd
f=0
cur=-1 max=2.14748e+09
Segmentation fault (core dumped)

6.2-RELEASE amd64> gdb ./ddd ddd.core
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...
Core was generated by `ddd'.
Program terminated with signal 11, Segmentation fault.
#0  0x7fffffff in ?? ()
(gdb) bt
#0  0x7fffffff in ?? ()
#1  0xffffced4 in ?? ()
#2  0x00000000 in ?? ()
#3  0x00000000 in ?? ()
#4  0x00000001 in ?? ()
#5  0xffffcf28 in ?? ()
#6  0x00000000 in ?? ()
#7  0xffffcee8 in ?? ()
#8  0x080515b5 in atexit ()
Cannot access memory at address 0x3
(gdb) q

6.2-RELEASE amd64> gdb ./ddd 
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...
(gdb) break main
Breakpoint 1 at 0x804825c: file ddd.c, line 41.
(gdb) run
Starting program: /home/users/alis/misc/F/F+C/ddd 

Breakpoint 1, main () at ddd.c:41
41              float f=0.0;
(gdb) step
43              printf("f=%g\n", f);
(gdb) 
f=0
44              bbb(&f);
(gdb) 
bbb (f=0xffffcea4) at ddd.c:18
18              if (!flag)
(gdb) 
21              if (!getrlimit(RLIMIT_CPU, &rlim)) {
(gdb) info frame 0
Stack frame at 0xffffce80:
 eip = 0x80481d1 in bbb (ddd.c:21); saved eip 0x8048282
 called by frame at 0xffffceb0
 source language c.
 Arglist at 0xffffce78, args: f=0xffffcea4
 Locals at 0xffffce78, Previous frame's sp is 0xffffce80
 Saved registers:
  ebp at 0xffffce78, eip at 0xffffce7c
(gdb) info frame 1
Stack frame at 0xffffceb0:
 eip = 0x8048282 in main (ddd.c:44); saved eip 0x8048106
 caller of frame at 0xffffce80
 source language c.
 Arglist at 0xffffcea8, args: 
 Locals at 0xffffcea8, Previous frame's sp is 0xffffceb0
 Saved registers:
  ebp at 0xffffcea8, eip at 0xffffceac
(gdb) step
22                      printf("cur=%g max=%g\n",
(gdb) info frame 0
Stack frame at 0xffffce80:
 eip = 0x80481e8 in bbb (ddd.c:22); saved eip 0x7fffffff
 called by frame at 0xffffce84
 source language c.
 Arglist at 0xffffce78, args: f=0xffffcea4
 Locals at 0xffffce78, Previous frame's sp is 0xffffce80
 Saved registers:
  ebp at 0xffffce78, eip at 0xffffce7c
(gdb) info frame 1
Stack frame at 0xffffce84:
 eip = 0x7fffffff; saved eip 0xffffcea4
 called by frame at 0xffffce88, caller of frame at 0xffffce80
 Arglist at 0xffffce7c, args: 
 Locals at 0xffffce7c, Previous frame's sp is 0xffffce84
 Saved registers:
  ebp at 0xffffce78, eip at 0xffffce80
(gdb) info frame 2
Stack frame at 0xffffce88:
 eip = 0xffffcea4; saved eip 0x0
 called by frame at 0xffffce8c, caller of frame at 0xffffce84
 Arglist at 0xffffce80, args: 
 Locals at 0xffffce80, Previous frame's sp is 0xffffce88
 Saved registers:
  ebp at 0xffffce78, eip at 0xffffce84
(gdb) info frame 3
Stack frame at 0xffffce8c:
 eip = 0x0; saved eip 0x0
 called by frame at 0xffffce90, caller of frame at 0xffffce88
 Arglist at 0xffffce84, args: 
 Locals at 0xffffce84, Previous frame's sp is 0xffffce8c
 Saved registers:
  ebp at 0xffffce78, eip at 0xffffce88
(gdb) step
cur=-1 max=2.14748e+09
25                      if (rlim.rlim_cur != RLIM_INFINITY)
(gdb) 
28                              *f = (float)rlim.rlim_max;
(gdb) 
36              flag = 0;
(gdb) 
37      }
(gdb) 

Program received signal SIGSEGV, Segmentation fault.
0x7fffffff in ?? ()
(gdb) c
Continuing.

Program terminated with signal SIGSEGV, Segmentation fault.
The program no longer exists.
(gdb) q

	I think, this problem similar or connected with one in the
	amd64/110655 bug report ?

>How-To-Repeat:
	Following very simple code ddd.c
	---------cut here---------
#include <sys/types.h>
#include <sys/time.h>
#include <sys/resource.h>

#include <stdio.h>
#include <stdlib.h>
#include <errno.h>
#include <string.h>

static int flag = 1;

void bbb(float *);

void bbb(float *f)
{
	struct rlimit rlim;

	if (!flag)
		return;

	if (!getrlimit(RLIMIT_CPU, &rlim)) {
		printf("cur=%g max=%g\n",
			(float)rlim.rlim_cur, (float)rlim.rlim_max);

		if (rlim.rlim_cur != RLIM_INFINITY)
			*f = (float)rlim.rlim_cur;
		else
			*f = (float)rlim.rlim_max;
	} else {
#ifdef CURE
		printf("errno=%i (%s)\n", errno, strerror(errno));
#else
		printf("errno=%i\n", errno);
#endif
	}
	flag = 0;
}

int main()
{
	float f=0.0;

	printf("f=%g\n", f);
	bbb(&f);
	printf("f=%g\n", f);

	f = 0.0;

	printf("f=%g\n", f);
	bbb(&f);
	printf("f=%g\n", f);

	exit(0);
}

	---------cut here---------
	compiled by following command line

	cc -g -W -Wall -m32 -static -B/usr/lib32 -o ddd ddd.c

	with 2) and 3) library sets ( mentioned in Environment: )
	produces SIGSEGV during execution under each of
	1) 6.2-RELEASE amd64
	2) 6.2-RELEASE i386
	3) 6.0-RELEASE i386

	Another trouble with 1) library set that the same code
	produces SIGILL under both i386 systems while still produce SIGSEGV
	under amd64. However we can see damaged stack frames in the ./ddd and
	normal in the ./ddd.CURE (compiled w/ -DCURE, see Fix: )

6.0-RELEASE i386> ./ddd.CURE
f=0
Illegal instruction (core dumped)

6.0-RELEASE i386> gdb ./ddd.CURE ddd.CURE.core
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-marcel-freebsd"...
Core was generated by `ddd.CURE'.
Program terminated with signal 4, Illegal instruction.
#0  0x0804e258 in __dtoa ()
(gdb) bt
#0  0x0804e258 in __dtoa ()
#1  0x0804c710 in __vfprintf ()
#2  0x0804dc3e in vfprintf ()
#3  0x08049b81 in printf ()
#4  0x08048216 in bbb (f=0xbfbfded4) at ddd.c:22
#5  0x080482b2 in main () at ddd.c:44
(gdb) q

6.0-RELEASE i386> ./ddd
f=0
Illegal instruction (core dumped)

6.0-RELEASE i386> gdb ./ddd ddd.core
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-marcel-freebsd"...
Core was generated by `ddd'.
Program terminated with signal 4, Illegal instruction.
#0  0x0804e038 in __dtoa ()
(gdb) bt
#0  0x0804e038 in __dtoa ()
#1  0x0804c4f0 in __vfprintf ()
#2  0x0804da1e in vfprintf ()
#3  0x08049a31 in printf ()
#4  0x08048212 in bbb (f=0xbfbfded4) at ddd.c:22
#5  0x7fffffff in ?? ()
#6  0xbfbfded4 in ?? ()
#7  0x00000000 in ?? ()
#8  0x00000000 in ?? ()
#9  0x080520c9 in atexit ()
Cannot access memory at address 0x3
(gdb) q

>Fix:
	Unknown for both SIGSEGV and SIGILL.

	SIGSEGV effect too subtle, because as workaround we can use, for
	example, #ifdef CURE cludge (see ddd.c text), which produces
	workable binary with -DCURE and 2) or 3) library sets.

	SIGILL with 1) library set effect possibly requires more accurate
	building of the /usr/lib32 under amd64.

>Release-Note:
>Audit-Trail:

From: "Scot Hetzel" <swhetzel@gmail.com>
To: "Isupov A.Yu." <isupov@moonhe.jinr.ru>
Cc: FreeBSD-gnats-submit@freebsd.org
Subject: Re: amd64/119771: troubles w/ -m32 executables on both amd64 and i386
Date: Fri, 18 Jan 2008 10:07:26 -0600

 Currently, building i386 programs under FreeBSD/amd64 is not
 supported.  The reason for this is you need the i386 includes to build
 your program, but they are not installed during a installworld (see
 stage 5.1 in src/Makefile.inc1).
 
 It's not clear in your report, are you recompiling the program under
 i386, or copying the binary from FreeBSD/amd64 to the FreeBSD/i386
 system?
 
 If you build your program under FreeBSD/i386, does your program run
 without these problems on i386 and amd64?
 
 Scot

From: "A.Yu.Isupov" <isupov@moonhe.jinr.ru>
To: bug-followup@FreeBSD.org
Cc: swhetzel@gmail.com
Subject: Re: amd64/119771: troubles w/ -m32 executables on both amd64
    and i386
Date: Sat, 19 Jan 2008 21:28:45 +0300 (MSK)

 *From:*	"Scot Hetzel" <swhetzel@gmail.com>
 *Date:*	Fri, 18 Jan 2008 10:07:26 -0600
 
 >Currently, building i386 programs under FreeBSD/amd64 is not
 >supported. The reason for this is you need the i386 includes to build
 >your program, but they are not installed during a installworld (see
 >stage 5.1 in src/Makefile.inc1).
 
   I assume, that all needed includes are the same under amd64 and i386...
 Problems are not connected with sizeof(int) or prototyping.
   Unfortunately, I can't port my program (that is cernlib) to 64-bit
 (I try !), because one intensively uses int (and integer*4 :) to store
 pointers, so I need to compile it in 32-bit environment - if possible,
 on FreeBSD/amd64, if not - I should choose to continue using the
 FreeBSD/i386 on 64-bit CPU :(
   Note, that Sun's OpenLook (ports/x11-toolkits/xview{,-clients}) compiled,
 but not work under amd64 for the same reasons - pointer should fit into int.
 However 32-bit binaries are OK.
   At least, I encounter too less problematic places (really two - syscalls
 getrlimit() and lseek(), see below) during 32-bit compiling in comparison with
 porting to 64-bit...
 
 >It's not clear in your report, are you recompiling the program under
 >i386, or copying the binary from FreeBSD/amd64 to the FreeBSD/i386
 >system?
 
   Failed binary produced under FreeBSD/amd64 as static w/ -m32
 and executed on FreeBSD/amd64 and (after copying :) on FreeBSD/i386 -
 with the same faulty results.
 
 >If you build your program under FreeBSD/i386, does your program run
 >without these problems on i386 and amd64?
 
   Yes, binary produced under FreeBSD/i386 as static have not a problem
 during execution under both FreeBSD/i386 and FreeBSD/amd64.
 
   So I conclude, that problem possibly in FreeBSD/amd64's 32-bit
 compatibility support, at least in syscall getrlimit().
 
   Furthermore, I have now yet another example of faulty syscall - lseek().
 Example text (see below) compiled natively under i386 and amd64 works as
 expected (outputs the same):
 
 i386> ./tseek.32
 or
 amd64> ./tseek.64
 
 fildes=3, nbdo=0
 isw=0, errno=0
 1 stat=0
 1 write(): res=4096, errno=0
 fildes=3, nbdo=8192
 isw=8192, errno=0
 2 stat=0
 2 write(): res=4096, errno=0
 fildes=3, nbdo=4096
 isw=4096, errno=0
 3 stat=0
 3 write(): res=4096, errno=0
 
   However compiled under amd64 as
 
 	cc -c -g -W -Wall -m32 -o tseek.o tseek.c
 	cc -c -g -W -Wall -m32 -o cfseek.o cfseek.c
 	cc -g -W -Wall -m32 -static -B/usr/lib32 -o tseek tseek.o cfseek.o
 
 says:
 
 amd64> ./tseek.32on64
 fildes=3, nbdo=0
 isw=0, errno=0
 1 stat=0
 1 write(): res=4096, errno=0
 fildes=3, nbdo=8192
 isw=-1, errno=22
  error in CFSEEK: Invalid argument
 2 stat=-1
 2 write(): res=4096, errno=0
 fildes=3, nbdo=4096
 isw=-1, errno=22
  error in CFSEEK: Invalid argument
 3 stat=-1
 3 write(): res=4096, errno=0
 
   Produced output file shows, that lseek() really does nothing when failed.
 
   Note, that effect also subtle and depends on statements near (before and
 after) lseek(), and totally absent in simplified example, where wrapper
 cfseek_() eliminated.
 
 -----cut here-tseek.c----
 #include <stdio.h>
 #include <stdlib.h>
 #include <unistd.h>
 #include <fcntl.h>
 #include <errno.h>
 #include <string.h>
 #include <strings.h>
 
 void cfseek_(int *lundes, int *medium, int *nwrec, int *jcrec, int *stat);
 
 int
 main()
 {
 	int fd;
 	int medium=0, nwrec, jcrec, stat=0;
 	off_t res=0;
 	char mbuf[4096];
 
 	errno = 0;
 	fd = open("./seek.dat", O_RDWR|O_TRUNC|O_CREAT, 0644);
 	if (fd==-1) {
 		printf("open(): %i\n", errno);
 		exit(1);
 	}
 
 	nwrec = 2;
 	jcrec = 0;
 	cfseek_(&fd, &medium, &nwrec, &jcrec, &stat);
 	printf("1 stat=%i\n", stat);
 
 	bzero((void *)mbuf, sizeof(mbuf));
 	strcpy(mbuf, "1wertyui");
 	strcpy(&mbuf[4088], "1xcvbnm");
 	errno = 0;
 	res = write(fd, mbuf, 4096);
 	printf("1 write(): res=%i, errno=%i\n", res, errno);
 
 	nwrec = 2;
 	jcrec = 1024;
 	cfseek_(&fd, &medium, &nwrec, &jcrec, &stat);
 	printf("2 stat=%i\n", stat);
 
 	bzero((void *)mbuf, sizeof(mbuf));
 	strcpy(mbuf, "2wertyui");
 	strcpy(&mbuf[4088], "2xcvbnm");
 	errno = 0;
 	res = write(fd, mbuf, 4096);
 	printf("2 write(): res=%i, errno=%i\n", res, errno);
 
 	nwrec = 1;
 	jcrec = 1024;
 	cfseek_(&fd, &medium, &nwrec, &jcrec, &stat);
 	printf("3 stat=%i\n", stat);
 
 	bzero((void *)mbuf, sizeof(mbuf));
 	strcpy(mbuf, "3wertyui");
 	strcpy(&mbuf[4088], "3xcvbnm");
 	errno = 0;
 	res = write(fd, mbuf, 4096);
 	printf("3 write(): res=%i, errno=%i\n", res, errno);
 
 	close(fd);
 
 	exit(0);
 }
 -----cut here-----
 
 -----cut here-cfseek.c----
 #define	NBYTPW	4
 
 #include <sys/types.h>
 #include <unistd.h>
 
 #include <stdio.h>
 #include <errno.h>
 
 void cfseek_(lundes, medium, nwrec, jcrec, stat)
       int  *lundes, *medium, *nwrec, *jcrec, *stat;
 {
       int  fildes;
       off_t  nbdo;
       off_t  isw;
 
 	errno = 0;
       fildes = *lundes;
       nbdo   = *jcrec * *nwrec * NBYTPW;
 	fprintf(stderr, "fildes=%i, nbdo=%i\n", fildes, nbdo);
       isw    = lseek (fildes, nbdo, SEEK_SET);
 	fprintf(stderr, "isw=%i, errno=%i\n", isw, errno);
       if (isw <  0)                goto trouble;
       *stat = 0;
       return;
 
 trouble:  *stat = -1;
           perror (" error in CFSEEK");
           return;
 }
 -----cut here-----
 
     Isupov A.
 

From: "Scot Hetzel" <swhetzel@gmail.com>
To: A.Yu.Isupov <isupov@moonhe.jinr.ru>
Cc: bug-followup@freebsd.org
Subject: Re: amd64/119771: troubles w/ -m32 executables on both amd64 and i386
Date: Sat, 19 Jan 2008 14:18:43 -0600

 On 1/19/08, A.Yu.Isupov <isupov@moonhe.jinr.ru> wrote:
 > *From:* "Scot Hetzel" <swhetzel@gmail.com>
 > *Date:* Fri, 18 Jan 2008 10:07:26 -0600
 >
 > >Currently, building i386 programs under FreeBSD/amd64 is not
 > >supported. The reason for this is you need the i386 includes to build
 > >your program, but they are not installed during a installworld (see
 > >stage 5.1 in src/Makefile.inc1).
 >
 >   I assume, that all needed includes are the same under amd64 and i386...
 > Problems are not connected with sizeof(int) or prototyping.
 
 The includes are not the same between amd64 and i386.
 
 sys/types.h pulls in machine/endian.h and machine/_types.h.  These two
 includes are different.
 
 That is why you would need to build the includes for i386 under amd64.
  An example of building the includes is in stage 5.1 of buildworld.
 
 >   Unfortunately, I can't port my program (that is cernlib) to 64-bit
 > (I try !), because one intensively uses int (and integer*4 :) to store
 > pointers, so I need to compile it in 32-bit environment - if possible,
 > on FreeBSD/amd64, if not - I should choose to continue using the
 > FreeBSD/i386 on 64-bit CPU :(
 
 You would need to create a 32-bit build environment similar to how
 buildworld stage 5.1 build the 32-bit libraries, or install
 FreeBSD/i386 into its own partition/directory and build it from there.
 
 1. Create directory to install FreeBSD/i386 into:
 
 mkdir /usr/home/build32
 
 2. Mount FreeBSD/i386 disc1 iso
 
 mount -t cd9660 /dev/cd0 /mnt
 
 or
 
 mount -t cd9660 /dev/`mdconfig -f 6.3-RELEASE-i386-disc1.iso` /mnt
 
 
 3. Install FreeBSD/i386 into /usr/home/build32
 
 cd /mnt/6.3-RELEASE/base
 DESTDIR=/usr/home/build32 install.sh
 
 4. link ld-elf.so.1 to ld-elf32.so.1
 
 cd /usr/home/build32/libexec
 ln -s ld-elf.so.1 ld-elf32.so.1
 cd ../usr/libexec
 ln -s ld-elf.so.1 ld-elf32.so.1
 
 Now place your source some where under /usr/home/build32, then chroot
 /usr/home/build32.  Change to the location of your sources and build
 your binary.
 
 Scot

From: "A.Yu.Isupov" <isupov@moonhe.jinr.ru>
To: bug-followup@freebsd.org
Cc: swhetzel@gmail.com
Subject: Re: amd64/119771: troubles w/ -m32 executables on both amd64
    and i386
Date: Sun, 20 Jan 2008 17:27:49 +0300 (MSK)

 >*From:*	"Scot Hetzel" <swhetzel@gmail.com>
 >*Date:*	Sat, 19 Jan 2008 14:18:43 -0600
 
 >The includes are not the same between amd64 and i386.
 >sys/types.h pulls in machine/endian.h and machine/_types.h. These two
 >includes are different.
 >That is why you would need to build the includes for i386 under amd64.
 >An example of building the includes is in stage 5.1 of buildworld.
 
   Because I already got ready 32-bit libs from 6.2-RELEASE i386
 (/usr/lib32 from amd64 contains code, produces SIGILL under i386,
 as I say above), so I do the same for i386 includes. And with addition
 
 	-nostdinc -I/usr/include32
 
 all reported strangeness are eliminated ! Thank you very very mach !!
 (I don't think about so dramatic effect from incorrect includes...)
 
 >You would need to create a 32-bit build environment similar to how
 >buildworld stage 5.1 build the 32-bit libraries, or install
 >FreeBSD/i386 into its own partition/directory and build it from there.
 
   This method SHOULD work, I understand. (The compiler suite will be used
 also 32-bit from i386, am I right ?) However such environment not so
 suitable for everyday working, namely building binaries with 32-bit
 cernlibs and running ones, and again, again, ...
 
   So receipt for me - to use under amd64 a native gcc with -m32, while
 /usr/lib32 and /usr/include32 are from corresponding i386 release,
 and to link -static binary for eliminating problems with correct dynamic
 linker and libs set (anyway, dynamic Xorg libs, as I seen, contains
 dependency names as absolute paths a la /usr/X11R6/lib/<lib>, so can't be used
 from /usr/X11R6/lib32). Because cernlibs itself are static only, the
 -static linking not so strong restriction...
 
   Thank you again !
 
     Isupov A.
 
State-Changed-From-To: open->closed 
State-Changed-By: jhb 
State-Changed-When: Mon Jan 21 15:02:12 UTC 2008 
State-Changed-Why:  
User was compiling -m32 binaries with 64-bit headers. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=119771 
>Unformatted:
 
