Jan Hudec wrote:
On Wed, Nov 23, 2005 at 08:21:55 +0200, MHD.Tayseer wrote:
Jan Hudec wrote:
The block expression might be quite hard sometimes. But the major problem
are
some of the __attribute__ specification -- asmlinkage (chages the calling
convention) and initcall/exitcall things (the linker script applies magic
to
them). And of course though the AT&T assembly syntax can be translated,
it's
not all *that* easy.
i'll read about those extensions .. but if it's a calling convention
attribute, can anyone fool the compiler to change the way it do a
function call ? is it possible ?
It's not fooling. It's a gcc feature. Gcc can add specific attributes
that change calling convention for particular function. That is mainly
how many arguments will be passed in registers.
One could workaround this for a compiler that does not support it -- the
only place where calling convention is significant is asmlinkage and
there it's enough to properly adapt the assembly calling it to the
calling convention given compiler uses.
i was meaning fooling my proprietery compiler and changing it's calling
conventions, not fooling gcc .. maybe my words was not clear ..
and if i wanna use cygwin .. i know that this question may now be asked
here but can i call windows executable (the compiler in my case) from
cygwin without recompiling/modifying it ?
Sure you can. As well as you can run cygwin executable from windows
directly,
as long as it can find the appropriate dynamic library.
so lets get the question asked at a lower layer .. i wanna run the
compiler i have (win executable) on cygwin .. as you've said that this
is possible as long as the needed dynamic libraries are found .. so can
cygwin import windows dll without modification ?
I did NOT say that. You can run native executable from cygwin exactly
the same way and under the same conditions as you can run them in any
other way. The only think you have to do is properly convert the cygwin
paths to native paths when passing arguments.
Cygwin is not a single thing that runs in a shell within windows. It's a
collection of stand-alone binaries -- native binaries -- that use a
cygwin library which provides POSIX API for them. But they are called
exactly as any other (native) binary and call each other that way. Thus
it never matters whether you are calling a cygwin or non-cygwin binary,
except for the way you pass filenames in arguments.
thank for clarifying it .. i understand how things are going now
well there is another thing must be changed .. the kernel Makefile is
written for gcc and the compilation options are written for gcc .. so i
have another step to look for it is the mapping between gcc flags and my
compiler flags .. the build process depends on a hirarichy Makefiles ..
it's hard to check all makefiles in all the hirarichy checking for gcc
options used to compile the kernel .. are they documented anywhere or is
there any way to them (before-when-after) kernel compilation
I don't know about any documentation unfotunately. But all the compiler
options and stuff is located in the top-level Makefile, Rules.make and
one Makefile for each platform. All the others just use ready-made
compilation commands.
this will direct me to a few files to check for compiler options there ..
Thank you for your help ..
MHD.Tayseer
--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive: http://mail.nl.linux.org/kernelnewbies/
FAQ: http://kernelnewbies.org/faq/
