[KJ] question regarding global symbols & namespace.pl script

[KJ] question regarding global symbols & namespace.pl script

[Godmar Back]

[-- Attachment #1: Type: text/plain, Size: 1665 bytes --]

Hi,

I have a very basic question regarding global symbols.

Does the Linux kernel build system provide each kernel module with its own 
namespace for global symbols?

For instance, Keith Owens points out in an old email that "there are
guaranteed to
be conflicts on static and global but unexported symbols" (within one module:
http://www.ussg.iu.edu/hypermail/linux/kernel/9909.0/0433.html), which seems 
to imply that only exported symbols of a module  are entered into the global 
namespace and that programmers can use  global symbols to communicate
across .o files with a module freely.

However, if a given subsystem is not built as a module, but rather
using the 'y'
option builtin to the kernel, how does the linker know how to respect
these per-module
namespaces?

Or is it possible that - depending on the configuration - a global symbol might 
cause a doubly-defined error in one (non-module) build configuration,
but not when
built as a module? 

I tried the namespace.pl script Keith wrote, however, I'm getting numerous 
messages such as this one when running namespace.pl in the Linux 
kernel top-level dir:

No source file found for arch/i386/kernel/process.o
...

despite the fact that arch/i386/kernel/process.c exists.
Could this be due to tool incompatibilities?
For instance, objdump -s -j .comment shows:
arch/i386/kernel/process.o:     file format elf32-i386

Contents of section .comment:
 0000 00474343 3a202847 4e552920 332e3100  .GCC: (GNU) 3.1.

whereas namespace.pl seems to expect:
/GCC\:.*GCC\:/m
(?)
Note this is on a 2.6.8.1 kernel build.

I would be helpful for any answers, particularly to my first question.

Thanks!

 - Godmar

[-- Attachment #2: Type: text/plain, Size: 167 bytes --]

_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
http://lists.osdl.org/mailman/listinfo/kernel-janitors

Re: [KJ] question regarding global symbols & namespace.pl script

[maximilian attems]

[-- Attachment #1: Type: text/plain, Size: 289 bytes --]

hello,

On Tue, 01 Feb 2005, Godmar Back wrote:

> I have a very basic question regarding global symbols.
<snip>

please ask on kernelnewbies.
aka -> http://www.kernelnewbies.org/

this list is about the kernel janitor project.
aka - http://janitor.kernelnewbies.org/

happy hacking
maks


[-- Attachment #2: Type: text/plain, Size: 167 bytes --]

_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
http://lists.osdl.org/mailman/listinfo/kernel-janitors

Re: [KJ] question regarding global symbols & namespace.pl script

[Randy.Dunlap]

Godmar Back wrote:
> Hi,
> 
> I have a very basic question regarding global symbols.
> 
> Does the Linux kernel build system provide each kernel module with its own 
> namespace for global symbols?
>
> For instance, Keith Owens points out in an old email that "there are
> guaranteed to
> be conflicts on static and global but unexported symbols" (within one module:
> http://www.ussg.iu.edu/hypermail/linux/kernel/9909.0/0433.html), which seems 
> to imply that only exported symbols of a module  are entered into the global 
> namespace and that programmers can use  global symbols to communicate
> across .o files with a module freely.

That sounds right to me.

> However, if a given subsystem is not built as a module, but rather
> using the 'y'
> option builtin to the kernel, how does the linker know how to respect
> these per-module namespaces?

First one I see is this:

dev is multiply defined in :-
	drivers/isdn/i4l/isdn_common.o
	sound/oss/wavfront.o

and both of these have a variable 'dev' that is not static and not
exported.  It looks like they show up in the System.map file as
having a numbered suffix added to them, like dev.4 and dev.6 .

There was a recent bug where 2 drivers used a variable name of
'debug' for a debug flag (duh).  One of them had to be changed.
Both of them should have been changed IMO.

Why weren't these debug.1 and debug.2 ?  I dunno.  Maybe because
they were module parameters (?).

Anyway, all of this is an experiment that you can do at home.  :)

> Or is it possible that - depending on the configuration - a global symbol might 
> cause a doubly-defined error in one (non-module) build configuration,
> but not when built as a module?
 >
> I tried the namespace.pl script Keith wrote, however, I'm getting numerous 
> messages such as this one when running namespace.pl in the Linux 
> kernel top-level dir:
> 
> No source file found for arch/i386/kernel/process.o

I didn't see that one, or any that were incorrect AFAIK (of the "No
source file found" message).  For me these all came from
objects that were named differently than their source files
by the Makefiles.

> ...
> 
> despite the fact that arch/i386/kernel/process.c exists.
> Could this be due to tool incompatibilities?
> For instance, objdump -s -j .comment shows:
> arch/i386/kernel/process.o:     file format elf32-i386
> 
> Contents of section .comment:
>  0000 00474343 3a202847 4e552920 332e3100  .GCC: (GNU) 3.1.
> 
> whereas namespace.pl seems to expect:
> /GCC\:.*GCC\:/m
> (?)
> Note this is on a 2.6.8.1 kernel build.
> 
> I would be helpful for any answers, particularly to my first question.

Mine also says that (like yours), I don't get it....

Keith is definitely the best person to ask about this.

rddunlap@gargoyle:/mnt/box/linux-2611-rc2-bk5/arch/i386/kernel> 
objdump -s -j .comment process.o

process.o:     file format elf32-i386

Contents of section .comment:
  0000 00474343 3a202847 4e552920 332e332e  .GCC: (GNU) 3.3.
  0010 33202853 75534520 4c696e75 782900    3 (SuSE Linux).

-- 
~Randy


_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
http://lists.osdl.org/mailman/listinfo/kernel-janitors

Re: [KJ] question regarding global symbols & namespace.pl script

[Godmar Back]

[-- Attachment #1: Type: text/plain, Size: 681 bytes --]

FWIW, I followed the advice and asked Matt Domsch on kernelnewbies and
he told me that the module namespaces are *not* intentionally
separated.

Rather, the fact that two modules sometimes define global symbols by
the same name is only an artifact of people testing their kernels in
module-only configurations only where it doesn't show up because
insmod hides unexported global symbols.

Apparently, an option "make allyesconfig" exists that will force all
modules to be compiled with 'y' so that these clashes become apparent.
Not allowing global name clashes is now the official policy of the
kernel maintainers.  I assume that's why namespace.pl was added in
2.6.9.

 - Godmar

[-- Attachment #2: Type: text/plain, Size: 167 bytes --]

_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
http://lists.osdl.org/mailman/listinfo/kernel-janitors

Re: [KJ] question regarding global symbols & namespace.pl script

[Godmar Back]

[-- Attachment #1: Type: text/plain, Size: 890 bytes --]

Regarding the namespace.pl issue, it seems that this script is not
intended to be run from the command line without setting the srctree
and objtree environment variables first.

The reason is that File::Find apparently chdir's into the directory
where the file is located, so the test on line 176: if (! -e
"$source.c" fails because $source is set to
arch/i386/process/kernel.c, but the current directory is already
./arch/i386/kernel. I saw in an strace that stat64("process.o")
succeeded right before stat64("arch/i386/process/kernel.c") failed. It
works fine with setting objtree and srctree beforehand.

The problem with GNU vs GCC might be an unrelated issue, but since the
.c file existed, it should not have executed the code that failed.

Thanks!

 - Godmar

ps: I apologize for the linebreaks in this email - does anybody know
how to use gmail with a monospace font in a htmlarea?

[-- Attachment #2: Type: text/plain, Size: 167 bytes --]

_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
http://lists.osdl.org/mailman/listinfo/kernel-janitors