On Mon, Jul 12, 1999 at 01:20:42PM -0700, Bill Studenmund wrote:
> On Tue, 13 Jul 1999 nigel@ind.tansu.com.au wrote:
> 
> > 
> > source came from the kernel tarball. The problem is that when I link
> > against this code, many kernel globals are defined in each .o file.
> > 
> > e.g. kernel_pmap_store, kmem_object and kernel_object are defined in
> >      both ext2fs_balloc.c and ext2fs_alloc.c
> > 
> > 
> > 1) Can someone who is familiar with the kernel source work out
> >    how this code is normally compiled when a kernel is build ?
> >    I cannot work out how it would actually compile, because at
> >    link time the same thing would happen.
> 
> Let me see if I can explain things coherently.
> 
> In traditional unix executables, there are two types of data. Ones
> initialized to a specific value which go in the .data section, and ones
> which are implicitly initialized to zero, which go into the .bss section.
> The .bss section isn't really in the executable, it's just a chunk of
> memory which is zeroed on exec.
> 
> The lines you're talking about are:
> 
> struct pmap kernel_pmap_store;   etc. i.e. struct foo bar.
> 
> As they don't initialize bar to a specific value, they go in .bss.
> 
> If one had been something like 'struct foo bar = {"zippy", "zappy",
> "zoo"}', as it sets a specific value, it'd go into .data.
> 
> What the gnu linker will do is merge multiple "identical" .bss symbols
> together, and will merge them with one .data symbol. 
> 
> So 100 files can say "struct foo bar" and you'll get exactly one struct
> foo bar in the output binary.
> 
> It's kinda like saying "extern struct foo bar" everywhere but without
> having to remember to say "struct foo bar" explicitly in one file.
> 
> Does that help? I'm not sure how to get Metrowerks to do this... Are there
> linker options?

Why not fix the sources -- I tend to consider it a bug to define a variable
more than once (of course declaring several places is ok) ??

- Erik