"N" symbols and System.map
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
Quoted 2 lines
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
Quoted 6 lines · H. Peter Anvin
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
_endis 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.
Signature · 3 lines
Andreas Schwab, [email protected] GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Quoted 10 lines · Andreas Schwab
Quoted 6 lines · H. Peter Anvin
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
_endis 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
Quoted 17 lines · Sam Ravnborg
Quoted 9 lines · Andreas Schwab
Quoted 6 lines · H. Peter Anvin
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
_endis 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 = .; }
Quoted 5 lines
And I see:
c1834000N_endThis 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
Quoted 19 lines · H. Peter Anvin
Quoted 18 lines · Sam Ravnborg
Quoted 10 lines · Andreas Schwab
Quoted 7 lines · H. Peter Anvin
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_endis 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 = .; }
Quoted 8 lines
Quoted 5 lines
And I see:
c1834000N_endThis 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
Quoted 1 line · Sam Ravnborg
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.
Signature · 3 lines
Andreas Schwab, [email protected] GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Quoted 10 lines · Andreas Schwab
Quoted 1 line · Sam Ravnborg
Andreas - can you explain what is happning here?
My best guess would be that it has to do with the fact that the
_endsymbol 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_endsymbol 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
Quoted 4 lines
My best guess would be that it has to do with the fact that the
_endsymbol 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
Quoted 9 lines · 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
_endis 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
Quoted 11 lines · Sam Ravnborg
Quoted 9 lines · 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
_endis 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?
Quoted 7 lines
Peter - what is status here?
Do you see
_endtagged N with -tip?
We landed a lot of changes tovmlinux.ldsthere.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
Quoted 14 lines · H. Peter Anvin
Quoted 13 lines · Sam Ravnborg
Quoted 9 lines · 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
_endis 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?
Quoted 8 lines
Quoted 5 lines
Do you see
_endtagged N with -tip?
We landed a lot of changes tovmlinux.ldsthere.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
Quoted 14 lines · Sam Ravnborg
Quoted 13 lines · H. Peter Anvin
Quoted 12 lines · Sam Ravnborg
Quoted 9 lines · 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
_endis 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?
Quoted 9 lines
Quoted 7 lines
Quoted 5 lines
Do you see
_endtagged N with -tip?
We landed a lot of changes tovmlinux.ldsthere.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