Linux-Development-Sys Digest #373, Volume #8 Sun, 24 Dec 00 07:13:11 EST
Contents:
compiled executable and OS ? ([EMAIL PROTECTED])
Re: compiled executable and OS ? (Kaz Kylheku)
[OT] Re: compiled executable and OS ? ("Arthur H. Gold")
Re: compiled executable and OS ? ([EMAIL PROTECTED])
Re: compiled executable and OS ? ("Karl Heyes")
Re: compiled executable and OS ? (Kaz Kylheku)
Glibc-2.1.3 install_root problem
Re: compiled executable and OS ? (Hartmann Schaffer)
Re: compiled executable and OS ? (Hartmann Schaffer)
Glibc-2.1.3 install_root problem
Re: pivot_root and ramfs (really just pivot_root) ([EMAIL PROTECTED])
ioctl not linked to anything? ("Guennadi V. Liakhovetski")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: compiled executable and OS ?
Date: Sat, 23 Dec 2000 22:43:48 GMT
a compiled program, say by MS vc compiles a program that can
be run directly by the processor.
similarly a program compiled by say another compiler on Linux
OS compiles so that it can be run directly by the processor(cpu).
ofcourse a linux executable will not run on NT.
well, why not , if both the executables have instructions that
are understood by the processor. where does the OS come into
play here ?
please post/email your responses asap.
thanks
Sent via Deja.com
http://www.deja.com/
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: compiled executable and OS ?
Reply-To: [EMAIL PROTECTED]
Date: Sat, 23 Dec 2000 23:00:44 GMT
On Sat, 23 Dec 2000 22:43:48 GMT, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
>a compiled program, say by MS vc compiles a program that can
>be run directly by the processor.
>similarly a program compiled by say another compiler on Linux
>OS compiles so that it can be run directly by the processor(cpu).
>ofcourse a linux executable will not run on NT.
>well, why not , if both the executables have instructions that
>are understood by the processor. where does the OS come into
>play here ?
Because an executable is not just machine language instructions.
It also contains other information, such as the initial data for
static variables, and unresolved references to functions and objects
that are not defined in that program.
How an executable is structured and how it is bound to its execution
environment is very operating-system-specific.
If you wanted to, say, run a Linux executable on NT, you would need a loader
which understands the executable format, and you would need libraries wihch
provide all the run time support that the executable needs. You could even use
the exact same libraries, but then you would need a kernel emulation layer to
provide Linux-compatible system calls.
------------------------------
Date: Sat, 23 Dec 2000 17:05:12 -0600
From: "Arthur H. Gold" <[EMAIL PROTECTED]>
Subject: [OT] Re: compiled executable and OS ?
[EMAIL PROTECTED] wrote:
>
> a compiled program, say by MS vc compiles a program that can
> be run directly by the processor.
> similarly a program compiled by say another compiler on Linux
> OS compiles so that it can be run directly by the processor(cpu).
>
> ofcourse a linux executable will not run on NT.
> well, why not , if both the executables have instructions that
> are understood by the processor. where does the OS come into
> play here ?
The system calls, i.e. anything that interacts with the
underlying hardware, are different.
HTH,
--ag
>
> please post/email your responses asap
Post here. Read here.
--
Artie Gold, Austin, TX (finger the cs.utexas.edu account
for more info)
mailto:[EMAIL PROTECTED] or mailto:[EMAIL PROTECTED]
--
A: Yes I would. But not enough to put it out.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: compiled executable and OS ?
Date: Sat, 23 Dec 2000 23:34:38 GMT
makes things a lot clearer.
so you are saying that a compiled executable does not directly
run the instructions (contained in it) to the cpu. as the kernel
of the OS would do so. Also it would need other info that would
be contained in the executable. The kernel would then run ie
execute the instructions along with the data through the cpu
of the computer.... right ??
hence the compilers are kernel(ie OS) specific in addition to
the cpu. right ?? what about assemblers then ??
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> On Sat, 23 Dec 2000 22:43:48 GMT, [EMAIL PROTECTED]
> <[EMAIL PROTECTED]> wrote:
> >a compiled program, say by MS vc compiles a program that can
> >be run directly by the processor.
> >similarly a program compiled by say another compiler on Linux
> >OS compiles so that it can be run directly by the processor(cpu).
>
> >ofcourse a linux executable will not run on NT.
> >well, why not , if both the executables have instructions that
> >are understood by the processor. where does the OS come into
> >play here ?
>
> Because an executable is not just machine language instructions.
> It also contains other information, such as the initial data for
> static variables, and unresolved references to functions and objects
> that are not defined in that program.
>
> How an executable is structured and how it is bound to its execution
> environment is very operating-system-specific.
>
> If you wanted to, say, run a Linux executable on NT, you would need a
loader
> which understands the executable format, and you would need libraries
wihch
> provide all the run time support that the executable needs. You
could even use
> the exact same libraries, but then you would need a kernel emulation
layer to
> provide Linux-compatible system calls.
>
Sent via Deja.com
http://www.deja.com/
------------------------------
From: "Karl Heyes" <[EMAIL PROTECTED]>
Subject: Re: compiled executable and OS ?
Date: Sun, 24 Dec 2000 02:35:32 +0000
In article <923cqe$shl$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
wrote:
> makes things a lot clearer.
>
> so you are saying that a compiled executable does not directly run
> the instructions (contained in it) to the cpu. as the kernel of the
> OS would do so. Also it would need other info that would be
> contained in the executable. The kernel would then run ie execute
> the instructions along with the data through the cpu of the
> computer.... right ??
>
Not really. An executable contains CPU specific instructions, but the
environment that is available to the program can vary. between linux
win 9x - a lot. between linux / solaris not so much.
Standards like POSIX define interfaces for programs to access system
resources as things like hard-drives are not directly accessible.
Hitting hardware is usually a job of the kernel, the exception
being X which is contained in the X server, even that has kernel
elements like DRI, fb etc.
> hence the compilers are kernel(ie OS) specific in addition to the
> cpu. right ?? what about assemblers then ??
>
The kernel is part of the OS. compilers/assemblers look to libraries
for the OS. libraries can vary between OS, but you could run
different linux kernels with the same library. You can't use a
linux library on say solaris x86 as the syscall table will be
different, even though it's the say CPU. With those ddifferences
you need an emulation layer like ibcs. The core instructions are
not altered but the calls to the libaries/kernel are handled
karl.
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: compiled executable and OS ?
Reply-To: [EMAIL PROTECTED]
Date: Sun, 24 Dec 2000 02:37:37 GMT
On Sat, 23 Dec 2000 23:34:38 GMT, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
>makes things a lot clearer.
>
>so you are saying that a compiled executable does not directly
>run the instructions (contained in it) to the cpu. as the kernel
>of the OS would do so. Also it would need other info that would
>be contained in the executable. The kernel would then run ie
>execute the instructions along with the data through the cpu
>of the computer.... right ??
The kernel would be involved in setting up the execution environment, such as
the layout of the address space. The kernel is not actually involved in
executing the instructions; once the process is set up in memory, it is allowed
to execute directly. (The kernel only steps in when certain instructions
are executed that generate a software interrupt or exception. The process
is suspended and the kernel executes some action on its behalf. This is
how all system calls are implemented).
>hence the compilers are kernel(ie OS) specific in addition to
>the cpu. right ?? what about assemblers then ??
No, more like, what is system specific is the linking stage. And of course the
interfaces; when you compile a C program that uses system libraries, the
declarations from the header files determine the linkage to those libraries. So
that is one system dependent aspect too.
The actions of the compiler itself are largerly independent of the operating
system. E.g. the GNU compiler is ported to many operating systems. For a given
processor type it will usually generate pretty much the same assembly language,
given a highly portable C source file.
However here is a counterexample: suppose the program uses getchar and the
library on one system has a macro for getchar but on another system it's a
function call, obviously the assembly will look different.
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Glibc-2.1.3 install_root problem
Date: Sun, 24 Dec 2000 03:50:22 GMT
Glibc-2.1.3 compiles and tests cleanly using the prefix=/usr.
But installation with root_install=/mnt/hda3/usr yields an error
which is listed below. My gosl is to build linux from scratch using
a different partition, naturally, and, while I was at it, upgrade from
version 2.0.7. Solutions accepted gratefully.
My email address is jrandyw at radiks.nt
make -C timezone subdir_install
make[2]: Entering directory `/usr/local/download/src/glibc-2.1.3/timezone'
/usr/bin/install -c /usr/local/download/src/build/timezone/tzselect
/mnt/hda3/usr/bin/tzselect.new
mv -f /mnt/hda3/usr/bin/tzselect.new /mnt/hda3/usr/bin/tzselect
/usr/local/download/src/build/elf/ld-linux.so.2 --library-path
/usr/local/download/src/build:/usr/local/download/src/build/math:
/usr/local/download/src/build/elf:/usr/local/download/src/build/nss:
/usr/local/download/src/build/nis:/usr/local/download/src/build/db2:
/usr/local/download/src/build/rt:/usr/local/download/src/build/resolv:
/usr/local/download/src/build/linuxthreads
/usr/local/download/src/build/timezone/zic -d /mnt/hda3/usr/share/zoneinfo
-L /dev/null -y ./yearistype africa
"/dev/null", line 1: input line of unknown type
"/dev/null", line 3: input line of unknown type
"/dev/null", line 4: input line of unknown type
"/dev/null", line 5: input line of unknown type
"/dev/null", line 6: input line of unknown type
make[2]: *** [/mnt/hda3/usr/share/zoneinfo/Africa/Algiers] Error 1
make[2]: Leaving directory `/usr/local/download/src/glibc-2.1.3/timezone'
make[1]: *** [timezone/subdir_install] Error 2
make[1]: Leaving directory `/usr/local/download/src/glibc-2.1.3'
make: *** [install] Error 2
------------------------------
From: [EMAIL PROTECTED] (Hartmann Schaffer)
Subject: Re: compiled executable and OS ?
Date: 23 Dec 2000 17:33:25 -0500
In article <9239r3$qh3$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
>a compiled program, say by MS vc compiles a program that can
>be run directly by the processor.
>similarly a program compiled by say another compiler on Linux
>OS compiles so that it can be run directly by the processor(cpu).
>
>ofcourse a linux executable will not run on NT.
>well, why not , if both the executables have instructions that
>are understood by the processor. where does the OS come into
>play here ?
two reasons:
1. the compiled and linked program must be in a format that the os
loader understands. in linux you can configure the kernel to
support binaries of several types, but afaik, ms does not provide
this ability. with the cygwin system by cygnus you might actually
come very close to execute linux binaries
2. typically, programs are linked against a couple of resident
libraries that provide an interface to the system. these libraries
tend to be incompatible between different oses.
there are a couple of "emulators" available that let you execute
binaries for one os on another os (cygnus, vmware, wine, dosemu), and
crosscompiling often is an option
hs
------------------------------
From: [EMAIL PROTECTED] (Hartmann Schaffer)
Subject: Re: compiled executable and OS ?
Date: 23 Dec 2000 20:52:56 -0500
In article <923cqe$shl$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
>makes things a lot clearer.
>
>so you are saying that a compiled executable does not directly
>run the instructions (contained in it) to the cpu. as the kernel
the binary executable contains an image of the instructions and
(initialized) data that make up the image of the program when it's
running
>of the OS would do so. Also it would need other info that would
>be contained in the executable. The kernel would then run ie
the extra information basically tells the kernel loader which part of
the file are instructions and which are data (let's ignore debugging
information for the time being). the kernel loader then allocates the
necessary memory for the various sections and reads the contents of
the file into it
>execute the instructions along with the data through the cpu
>of the computer.... right ??
once everything has been read in, it sets up a task descriptor
pointing to the allocated memory and puts that into a task list
>hence the compilers are kernel(ie OS) specific in addition to
only a very small section, the one that formats the image files. many
compilers use the assembler and linker to do it
>the cpu. right ?? what about assemblers then ??
same thing, and many compilers rely on the assembler to do this
hs
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Glibc-2.1.3 install_root problem
Date: Sun, 24 Dec 2000 05:55:14 GMT
Glibc-2.1.3 compiled and tested cleanly with prefix=/usr. Make install
(as root) with install_root=/mnt/dev3/ produced the following. I've
included just the last 30 lines. Suggestions and/or solutions sought.
My email, not well disguised, is jrandyw at radiks.net
The actual output is edited because of long lines (> 80) with a return
inserted on/before a '/'.
/usr/bin/install -c -m 644 locales/zh_CN /mnt/hda3/usr/share/i18n/locales/zh_CN
.././scripts/mkinstalldirs /mnt/hda3/usr/share/i18n/repertoiremaps
mkdir /mnt/hda3/usr/share/i18n/repertoiremaps
/usr/bin/install -c -m 644 repertoiremaps/charids.894 /mnt/hda3/usr/share/i18n
/repertoiremaps/charids.894
.././scripts/mkinstalldirs /mnt/hda3/usr/share/i18n/repertoiremaps
/usr/bin/install -c -m 644 repertoiremaps/mnemonic.ds /mnt/hda3/usr/share/i18n
/repertoiremaps/mnemonic.ds
(s=`cd ../sysdeps/generic && /bin/pwd`; \
cd /usr/local/download/src/build/localedata && \
sed -n 's/^stub_warning *(\([^)]*\).*$/#define __stub_\1/p' \
`sed -n -e '\@ ../sysdeps/generic/[^ ]*\.c@{; s@^.* ../sysdeps/generic
/\([^ ]*\.c\).*$@'"$s"'/\1@; h; }' \
-e '/stub-tag\.h/{; g; p; }' \
collate-test.d xfrm-test.d tst-fmon.d tst-rpmatch.d /dev/null` \
/dev/null) > /usr/local/download/src/build/localedata/stubsT
mv -f /usr/local/download/src/build/localedata/stubsT /usr/local/download/src
/build/localedata/stubs
make[2]: Leaving directory `/usr/local/download/src/glibc-2.1.3/localedata'
make -C timezone subdir_install
make[2]: Entering directory `/usr/local/download/src/glibc-2.1.3/timezone'
/usr/bin/install -c /usr/local/download/src/build/timezone/tzselect /mnt/hda3
/usr/bin/tzselect.new
mv -f /mnt/hda3/usr/bin/tzselect.new /mnt/hda3/usr/bin/tzselect
/usr/local/download/src/build/elf/ld-linux.so.2 --library-path /usr/local
/download/src/build:/usr/local/download/src/build/math:/usr/local/download
/src/build/elf:/usr/local/download/src/build/nss:/usr/local/download/src
/build/nis:/usr/local/download/src/build/db2:/usr/local/download/src/build
/rt:/usr/local/download/src/build/resolv:/usr/local/download/src/build
/linuxthreads /usr/local/download/src/build/timezone/zic -d /mnt/hda3/usr/share
/zoneinfo -L /dev/null -y ./yearistype africa
"/dev/null", line 1: input line of unknown type
"/dev/null", line 3: input line of unknown type
"/dev/null", line 4: input line of unknown type
"/dev/null", line 5: input line of unknown type
"/dev/null", line 6: input line of unknown type
make[2]: *** [/mnt/hda3/usr/share/zoneinfo/Africa/Algiers] Error 1
make[2]: Leaving directory `/usr/local/download/src/glibc-2.1.3/timezone'
make[1]: *** [timezone/subdir_install] Error 2
make[1]: Leaving directory `/usr/local/download/src/glibc-2.1.3'
make: *** [install] Error 2
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: pivot_root and ramfs (really just pivot_root)
Date: Sun, 24 Dec 2000 08:06:33 -0000
On Sat, 23 Dec 2000 13:39:02 -0800 urp <[EMAIL PROTECTED]> wrote:
| In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
| wrote:
|> if I had a
|> filesystem mounted as /ramfs/foo, what will happen to that filesystem
|> when the pivot_root call is done?
| All mount points get pivoted as well. You should have a mounted
| filesystem under /foo.
| The only thing you have to watch out for is program behavior after a
| pivot_root. Make sure to do chroots() on everything. As of today,
| pivot_root does that for you, but the man page indicates it could change
| and leave the chroots up to the affected programs.
If a program was already chroot at / when pivot_root happens, and if
pivot_root does not adjust chroots, isn't the chroot associated with
the internal inode, and thus references to / are now references to
the place where the old root was moved to? In that case, existing
processes would have no view of the new root. IWSTM that pivot_root
needs to change any process which has chroot=/ and cwd=/ else things
can be in an unrecoverable situation.
| Well, that, and mtab. I haven't figured out a good way to make the mtab
| for the original filesystem duplicated after the pivot_root. symbolic
| linking doesn't work, neither does copying.
In a previous project where I used initrd letting the kernel to the switch,
I just re-created mtab from /proc/mounts with a little fudging. Fortunately
for my current project, it will be so early in the game that not only will
my process be running as PID 1, but there will never have yet been any new
processes (although it will be the second program runing as PID 1) and the
/etc/mtab file will never have yet even existed.
--
=================================================================
| Phil Howard - KA9WGN | Dallas | http://linuxhomepage.com/ |
| [EMAIL PROTECTED] | Texas, USA | http://phil.ipal.org/ |
=================================================================
------------------------------
From: "Guennadi V. Liakhovetski" <[EMAIL PROTECTED]>
Subject: ioctl not linked to anything?
Date: Sun, 24 Dec 2000 11:39:15 +0000
Hi all
I am trying to run hdparm -d1 in a debugger (hdparm, glibc and the whole
drivers/block directory of the kernel compiled with the -g flag). Now,
when I come to the line
ioctl(fd, HDIO_SET_DMA, dma)
and press step... gdb merely steps over it as if it were a simple
C-command, whereas other ioctl calls can be debugged fine... What does
this mean?
Thankd
Guennadi
___
Dr. Guennadi V. Liakhovetski
Department of Applied Mathematics
University of Sheffield, U.K.
email: [EMAIL PROTECTED]
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list by posting to the
comp.os.linux.development.system newsgroup.
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Development-System Digest
******************************
