hi there,
When doing a 'nm' on the vmlinux I see that some different
symbols are at the same address. This seems very strange
to me. Can anyone explain this?
What I typed (to see the duplicates only)...
nm vmlinux-2.4.18-14 | awk 'BEGIN{oldval=01;} { if ($1==oldval) {
if(plast) { print "\n"; print oldrow;} print $0; plast=0} else plast=1;
oldrow=$0; oldval=$1}' - | more
What I saw....
[stuff removed...]
c0305a78 d emergency_lock
c0305a78 d emergency_pages
c0303100 d i8259A_irq_type
c0303100 D i8259A_lock
c0386628 B jiffies
c0386628 B jiffies_64
[stuff removed...]
Any idea?
Thanks again,
andy winton
On 6 Aug 2003, Andy Winton wrote:
> c0305a78 d emergency_lock
> c0305a78 d emergency_pages
>
> c0303100 d i8259A_irq_type
> c0303100 D i8259A_lock
>
> c0386628 B jiffies
> c0386628 B jiffies_64
For most of those, the explanation would be that you have zero-sized
symbols, for example a spinlock_t expands to an empty struct on an UP
build.
jiffies / jiffies_64 is a special case used to access the same variable as
a 32 vs 64 bit quantity. (see arch/*/vmlinux.lds*)
--Kai
On Wed, 6 Aug 2003, Andy Winton wrote:
> hi there,
>
> When doing a 'nm' on the vmlinux I see that some different
> symbols are at the same address. This seems very strange
> to me. Can anyone explain this?
>
> What I typed (to see the duplicates only)...
>
> nm vmlinux-2.4.18-14 | awk 'BEGIN{oldval=01;} { if ($1==oldval) {
> if(plast) { print "\n"; print oldrow;} print $0; plast=0} else plast=1;
> oldrow=$0; oldval=$1}' - | more
>
> What I saw....
>
> [stuff removed...]
> c0305a78 d emergency_lock
> c0305a78 d emergency_pages
>
> c0303100 d i8259A_irq_type
> c0303100 D i8259A_lock
>
> c0386628 B jiffies
> c0386628 B jiffies_64
> [stuff removed...]
>
> Any idea?
>
> Thanks again,
>
> andy winton
>
They are aliases. GCC uses 'weak aliases' so objects may be accessed
at the same location with different names. This seems strange for
'C', but perfectly normal for assembly. For instance...
a:
b:
c: .long 0
.global a
.global b
.global c
All 4 objects refer to the same memory location. "a" may actually
be a char[4], "b" may actually be a short[2] and "c" a long. So
we have the equivalent of a 'C' union. Some spin-locks and
other aggregate types end up being represented this way.
That said, there seems to be a problem.
"i8259A_lock" is a spin-lock in i8259.c, line 133 (version 2.4.20)
"i8259A_irq_type" is a structure in i8259.c, line 151.
It is static, therefore can not be visible outside the file, plus
it can't exist at the same address as the spin-lock. So, some
tool is broken. Look at System.map. On my system I see:
c01fd9c0 D i8259A_lock
c01fd9e0 d i8259A_irq_type
These are (correctly) at different addresses, but the static
structure is still visible, which must not happen! So, you
have certainly discovered something that's not right. Perhaps
the 'd' stuff is "really" not visible? If so, what 'th..???
Cheers,
Dick Johnson
Penguin : Linux version 2.4.20 on an i686 machine (797.90 BogoMips).
Note 96.31% of all statistics are fiction.
On Wednesday 06 August 2003 08:32, Richard B. Johnson wrote:
> On Wed, 6 Aug 2003, Andy Winton wrote:
> > nm vmlinux-2.4.18-14 | awk 'BEGIN{oldval=01;} { if ($1==oldval) {
> > if(plast) { print "\n"; print oldrow;} print $0; plast=0} else plast=1;
> > oldrow=$0; oldval=$1}' - | more
[snip]
> c01fd9c0 D i8259A_lock
> c01fd9e0 d i8259A_irq_type
>
> These are (correctly) at different addresses, but the static
> structure is still visible, which must not happen! So, you
> have certainly discovered something that's not right. Perhaps
> the 'd' stuff is "really" not visible? If so, what 'th..???
In nm(1) output, uppercase symbol types means the name is externally
available, lowercase symbol means it is local.
Even if an object is local, the object file still knows its name (for ELF,
anyways). Finding local "static" variables would be very annoying otherwise,
for porting code to a threaded application :)
--
Michael Driscoll, [email protected]
"A noble spirit embiggens the smallest man" -- J. Springfield