Anyone have a pointer to what we are really trying to accomplish
with .subsection and .previous in the in-line and asm stuff?
Like maybe a readme or coding style doc for in-line and asm code?
That was the main thing I tripped over while trying to build
a 2.5 kernel using the cygwin toolchain with an eye towards
uml under windows. I found very little documentation about
the directives themselves even in the gnu info stuff and nada,
except one thread about abstracting them in spinlocks,
bout how/why they are used in the kernel. They appear to be
elf specific which is why the i386pe stuff puked on them. I
assume that most of this is to maximize cache hits, but that's
just a guess. There are a largish handful of them scattered
around the kernel outside of locks. Any pointers would be appreciated.
Steve
On Thu, 27 Feb 2003, Steve Kenton wrote:
> Anyone have a pointer to what we are really trying to accomplish
> with .subsection and .previous in the in-line and asm stuff?
>
> Like maybe a readme or coding style doc for in-line and asm code?
>
> That was the main thing I tripped over while trying to build
> a 2.5 kernel using the cygwin toolchain with an eye towards
> uml under windows. I found very little documentation about
> the directives themselves even in the gnu info stuff and nada,
> except one thread about abstracting them in spinlocks,
> bout how/why they are used in the kernel. They appear to be
> elf specific which is why the i386pe stuff puked on them. I
> assume that most of this is to maximize cache hits, but that's
> just a guess. There are a largish handful of them scattered
> around the kernel outside of locks. Any pointers would be appreciated.
>
> Steve
> -
The data storage exists in ".sections". The common ones are:
.text Where the code is
.bss Data initialized upon startup to zeros.
.data Where non-local data are kept.
.rodata Where non-writable strings are put.
.othernames Defined by the implementor so that it can
remain isolated.
The "othernames" are things like __ex_table and _text_lock.
A subsection is a finer-granularity section. They can't be
named, only numbered. Since each of the ".sections" are
separate, one can set up a specific trap on a section. For
instance, one can grab an out-of-bounds access in a ".section"
without seg-faulting the whole kernel. This helps provide
for a recovery mechanism should the kernel try to write to
an invalid user-provided buffer.
The keyword ".previous" is shorthand for just that. It tells
the assembler to emit data and/or code according to the previous
section.
If you are writing code under cygwin, you should not be encountering
spin-locks and kernel-specific things. Perhaps you are including
the wrong header files? You should never do:
#include <linux/xxx.h>
#include <asm/xxx.h>
... unless you are writing modules. And you don't do that in cygwin.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
Why is the government concerned about the lunatic fringe? Think about it.
Actually, I was following up on some pointers from Jeff Dike on the
User Mode Linux home page about possibly running UML in a windows environment.
Jeff says that SMP has worked in the past and will again in the future
so I'm pretty sure that spinlocks will be needed ...
As a first pass to see where the problems were located I tried to build a
'host' kernel for i386 using the cygwin tool chain. That version of gcc produces
i386pe format output instead of elf which triggered the problem with .subsection
not being a recognized gas directive. I understand that .subsections force
things to be closely located within a section when there is no other logical
association and that they are not visible to the the linker which only deals with
sections. They only reason *I *can see for this is to improve cache hits but
I'm just guessing, hence the question.
FYI, by hacking out the .subsection/.previous directive I was able to build a
vmlinux for 2.5.59 using the cygwin tool chain under windows. Obviously it is
not useful as is, but there seem to be relatively few syntax and toolchain
problems to deal with. Hopefully the hard part of an actual UML port to windows
can be snarfed from the LINE project. Again based on a pointer from Jeff Dike.
Anyway, I'm just trying to get up to speed and was wondering *WHY* things are
done that way. Most of the in-line and asm stuff still looks like voodoo to me.
The .subsection/.previous just looks like a little blacker magic than normal.
Steve
>If you are writing code under cygwin, you should not be encountering
>spin-locks and kernel-specific things. Perhaps you are including
>>the wrong header files? You should never do:
>
> #include <linux/xxx.h>
> #include <asm/xxx.h>
>
>... unless you are writing modules. And you don't do that in cygwin.
>
>
>Cheers,
>Dick Johnson
>Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
>Why is the government concerned about the lunatic fringe? Think about it.
> Hopefully the hard part of an actual UML port to windows
> can be snarfed from the LINE project.
Check out umlwin32.sf.net. That's a mostly-working port of UML to Windows.
Jeff