"N" symbols and System.map

"N" symbols and System.map

[H. Peter Anvin]

Hi all,

right now, we filter out symbols that nm tag N, meaning "debugging 
symbols", from System.map.  However, at least on x86, the 
linker-generated symbol _end is tagged N, and in fact is the only N in 
the entire image.

Are there other architectures which would suffer if N were included in 
System.map, or would that be a reasonable thing to do?

	-hpa

RE: "N" symbols and System.map

[Luck, Tony]

> Are there other architectures which would suffer if N were included in
> System.map, or would that be a reasonable thing to do?

ia64 has no "N" symbols.  _end shows up as an "A" for me.

-Tony

Re: "N" symbols and System.map

[Andreas Schwab]

"H. Peter Anvin" <hpa@linux.intel.com> writes:

> right now, we filter out symbols that nm tag N, meaning "debugging
> symbols", from System.map.  However, at least on x86, the linker-generated
> symbol _end is tagged N, and in fact is the only N in the entire image.
>
> Are there other architectures which would suffer if N were included in
> System.map, or would that be a reasonable thing to do?

There should not be any N symbols unless you are using stabs debugging.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: "N" symbols and System.map

[Sam Ravnborg]

On Sat, May 02, 2009 at 01:10:18AM +0200, Andreas Schwab wrote:
> "H. Peter Anvin" <hpa@linux.intel.com> writes:
> 
> > right now, we filter out symbols that nm tag N, meaning "debugging
> > symbols", from System.map.  However, at least on x86, the linker-generated
> > symbol _end is tagged N, and in fact is the only N in the entire image.
> >
> > Are there other architectures which would suffer if N were included in
> > System.map, or would that be a reasonable thing to do?
> 
> There should not be any N symbols unless you are using stabs debugging.

We have in vmlinux:
        .end : AT(ADDR(.end) - LOAD_OFFSET) {
                _end = .;
        }


And I see:
c1834000 N _end

This is the _only_ 'N' symbol in my vmlinux.

	Sam

Re: "N" symbols and System.map

[H. Peter Anvin]

Sam Ravnborg wrote:
> On Sat, May 02, 2009 at 01:10:18AM +0200, Andreas Schwab wrote:
>> "H. Peter Anvin" <hpa@linux.intel.com> writes:
>>
>>> right now, we filter out symbols that nm tag N, meaning "debugging
>>> symbols", from System.map.  However, at least on x86, the linker-generated
>>> symbol _end is tagged N, and in fact is the only N in the entire image.
>>>
>>> Are there other architectures which would suffer if N were included in
>>> System.map, or would that be a reasonable thing to do?
>> There should not be any N symbols unless you are using stabs debugging.
> 
> We have in vmlinux:
>         .end : AT(ADDR(.end) - LOAD_OFFSET) {
>                 _end = .;
>         }
> 
> 
> And I see:
> c1834000 N _end
> 
> This is the _only_ 'N' symbol in my vmlinux.
> 

Yup, this is what happens.  I don't know why the linker does this, and 
if there is a way around it.

	-hpa

Re: "N" symbols and System.map

[Sam Ravnborg]

On Fri, May 01, 2009 at 05:00:39PM -0700, H. Peter Anvin wrote:
> Sam Ravnborg wrote:
> >On Sat, May 02, 2009 at 01:10:18AM +0200, Andreas Schwab wrote:
> >>"H. Peter Anvin" <hpa@linux.intel.com> writes:
> >>
> >>>right now, we filter out symbols that nm tag N, meaning "debugging
> >>>symbols", from System.map.  However, at least on x86, the 
> >>>linker-generated
> >>>symbol _end is tagged N, and in fact is the only N in the entire image.
> >>>
> >>>Are there other architectures which would suffer if N were included in
> >>>System.map, or would that be a reasonable thing to do?
> >>There should not be any N symbols unless you are using stabs debugging.
> >
> >We have in vmlinux:
> >        .end : AT(ADDR(.end) - LOAD_OFFSET) {
> >                _end = .;
> >        }
> >
> >
> >And I see:
> >c1834000 N _end
> >
> >This is the _only_ 'N' symbol in my vmlinux.
> >
> 
> Yup, this is what happens.  I don't know why the linker does this, and 
> if there is a way around it.

Andreas - can you explain what is happning here?
I can include 'N' symbols in System.map - but I have not yet reached
a level of understanding that make me go and do it.

	Sam

Re: "N" symbols and System.map

[Sam Ravnborg]

On Fri, May 01, 2009 at 05:00:39PM -0700, H. Peter Anvin wrote:
> Sam Ravnborg wrote:
> >On Sat, May 02, 2009 at 01:10:18AM +0200, Andreas Schwab wrote:
> >>"H. Peter Anvin" <hpa@linux.intel.com> writes:
> >>
> >>>right now, we filter out symbols that nm tag N, meaning "debugging
> >>>symbols", from System.map.  However, at least on x86, the 
> >>>linker-generated
> >>>symbol _end is tagged N, and in fact is the only N in the entire image.
> >>>
> >>>Are there other architectures which would suffer if N were included in
> >>>System.map, or would that be a reasonable thing to do?
> >>There should not be any N symbols unless you are using stabs debugging.
> >
> >We have in vmlinux:
> >        .end : AT(ADDR(.end) - LOAD_OFFSET) {
> >                _end = .;
> >        }
> >
> >
> >And I see:
> >c1834000 N _end
> >
> >This is the _only_ 'N' symbol in my vmlinux.
> >
> 
> Yup, this is what happens.  I don't know why the linker does this, and 
> if there is a way around it.

Andreas - can you explain what is happning here?
I can include 'N' symbols in System.map - but I have not yet reached
a level of understanding that make me go and do it.

	Sam

Re: "N" symbols and System.map

[Andreas Schwab]

Sam Ravnborg <sam@ravnborg.org> writes:

> Andreas - can you explain what is happning here?

My best guess would be that it has to do with the fact that the _end
symbol is attached to the .end section which is located before the debug
sections, but the .end section is empty, so the symbol has the same
address as the following debug section.  The ppc linker script does not
attach the _end symbol to any section, so it becomes an absolute symbol.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: "N" symbols and System.map

[H. Peter Anvin]

Andreas Schwab wrote:
> Sam Ravnborg <sam@ravnborg.org> writes:
> 
>> Andreas - can you explain what is happning here?
> 
> My best guess would be that it has to do with the fact that the _end
> symbol is attached to the .end section which is located before the debug
> sections, but the .end section is empty, so the symbol has the same
> address as the following debug section.  The ppc linker script does not
> attach the _end symbol to any section, so it becomes an absolute symbol.
> 

Yes; we used to do that in x86 too, but it messes up the post-processing 
for the relocatable kernel.

	-hpa

RE: "N" symbols and System.map

[Luck, Tony]

> My best guess would be that it has to do with the fact that the _end
> symbol is attached to the .end section which is located before the debug
> sections, but the .end section is empty, so the symbol has the same
> address as the following debug section.

Perhaps a good guess.  Putting something (". = . + PAGE_SIZE;") into
the .end section makes _end change type from "N" tp "B".

-Tony

Re: "N" symbols and System.map

[Sam Ravnborg]

On Fri, May 01, 2009 at 03:24:18PM -0700, H. Peter Anvin wrote:
> Hi all,
> 
> right now, we filter out symbols that nm tag N, meaning "debugging 
> symbols", from System.map.  However, at least on x86, the 
> linker-generated symbol _end is tagged N, and in fact is the only N in 
> the entire image.
> 
> Are there other architectures which would suffer if N were included in 
> System.map, or would that be a reasonable thing to do?

Peter - what is status here?

Do you see _end tagged N with -tip?
We landed a lot of changes to vmlinux.lds there.

Needless to say I have not included N symbols for now.

	Sam

Re: "N" symbols and System.map

[H. Peter Anvin]

Sam Ravnborg wrote:
> On Fri, May 01, 2009 at 03:24:18PM -0700, H. Peter Anvin wrote:
>> Hi all,
>>
>> right now, we filter out symbols that nm tag N, meaning "debugging 
>> symbols", from System.map.  However, at least on x86, the 
>> linker-generated symbol _end is tagged N, and in fact is the only N in 
>> the entire image.
>>
>> Are there other architectures which would suffer if N were included in 
>> System.map, or would that be a reasonable thing to do?
> 
> Peter - what is status here?
> 
> Do you see _end tagged N with -tip?
> We landed a lot of changes to vmlinux.lds there.
> 
> Needless to say I have not included N symbols for now.
> 

I haven't checked it for a bit, as my immediate need for it disappeared,
but I don't think it's changed.

	-hpa

Re: "N" symbols and System.map

[Sam Ravnborg]

On Fri, Jun 05, 2009 at 03:28:16PM -0700, H. Peter Anvin wrote:
> Sam Ravnborg wrote:
> > On Fri, May 01, 2009 at 03:24:18PM -0700, H. Peter Anvin wrote:
> >> Hi all,
> >>
> >> right now, we filter out symbols that nm tag N, meaning "debugging 
> >> symbols", from System.map.  However, at least on x86, the 
> >> linker-generated symbol _end is tagged N, and in fact is the only N in 
> >> the entire image.
> >>
> >> Are there other architectures which would suffer if N were included in 
> >> System.map, or would that be a reasonable thing to do?
> > 
> > Peter - what is status here?
> > 
> > Do you see _end tagged N with -tip?
> > We landed a lot of changes to vmlinux.lds there.
> > 
> > Needless to say I have not included N symbols for now.
> > 
> 
> I haven't checked it for a bit, as my immediate need for it disappeared,
> but I don't think it's changed.
We can revisit this if needed.

	Sam

Re: "N" symbols and System.map

[H. Peter Anvin]

Sam Ravnborg wrote:
> On Fri, Jun 05, 2009 at 03:28:16PM -0700, H. Peter Anvin wrote:
>> Sam Ravnborg wrote:
>>> On Fri, May 01, 2009 at 03:24:18PM -0700, H. Peter Anvin wrote:
>>>> Hi all,
>>>>
>>>> right now, we filter out symbols that nm tag N, meaning "debugging 
>>>> symbols", from System.map.  However, at least on x86, the 
>>>> linker-generated symbol _end is tagged N, and in fact is the only N in 
>>>> the entire image.
>>>>
>>>> Are there other architectures which would suffer if N were included in 
>>>> System.map, or would that be a reasonable thing to do?
>>> Peter - what is status here?
>>>
>>> Do you see _end tagged N with -tip?
>>> We landed a lot of changes to vmlinux.lds there.
>>>
>>> Needless to say I have not included N symbols for now.
>>>
>> I haven't checked it for a bit, as my immediate need for it disappeared,
>> but I don't think it's changed.
> We can revisit this if needed.
> 

FWIW:

c43e0000 N _end

	-hpa