* Re: [Ltt-dev] Linux Kernel Markers : sparc build issue
@ 2007-02-07 17:19 Mathieu Desnoyers
2007-02-07 18:46 ` Mathieu Desnoyers
` (4 more replies)
0 siblings, 5 replies; 6+ messages in thread
From: Mathieu Desnoyers @ 2007-02-07 17:19 UTC (permalink / raw)
To: sparclinux
It seems like I bust the 8k limit for the sparc GOT :
The kallsyms_addresses is 8614 lines long (for a 33.6kB total) in the .S,
and, according to
http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/Code-Gen-Options.html :
"If the GOT size for the linked executable exceeds a machine-specific
maximum size, you get an error message from the linker indicating that
-fpic does not work; in that case, recompile with -fPIC instead. (These
maximums are 8k on the SPARC and 32k on the m68k and RS/6000. The 386
has no such limit.)"
Mathieu
* Mathieu Desnoyers (mathieu.desnoyers@polymtl.ca) wrote:
> * Frank Ch. Eigler (fche@redhat.com) wrote:
> >
> > Perhaps you could post excerpts of "objdump -dr <file.o>", to see the
> > disassembly / relocations in question.
> >
> > - FChE
>
> Hi Frank,
>
> (this message follow up on
> http://listserv.shafik.org/pipermail/ltt-dev/2007-February/002212.html)
>
> compudj@amd64:~/obj/sparc$ PATH=/opt/crosstool/gcc-4.1.1-glibc-2.3.6/sparc-unknown-linux-gnu/bin sparc-unknown-linux-gnu-objdump -dr .tmp_kallsyms3.o
>
> .tmp_kallsyms3.o: file format elf32-sparc
>
> (that's all)
>
> By looking at what follows in more depth, it looks like the symbols I
> keep are relative to the beginning of the _text section and sparc would
> have a limit regarding this (maximum offset ? number of offsets relative
> to a symbol ?)
>
> Any insights are welcome,
>
> Mathieu
>
>
> link error :
>
> opt/crosstool/gcc-4.1.1-glibc-2.3.6/sparc-unknown-linux-gnu/bin/sparc-unknown-linux-gnu-ld -m elf32_sparc -T arch/sparc/kernel/vmlinux.lds arch/sparc/kernel/head.o arch/sparc/kernel/init_task.o init/built-in.o --start-group usr/built-in.o arch/sparc/kernel/built-in.o arch/sparc/mm/built-in.o arch/sparc/math-emu/built-in.o kernel/built-in.o mm/built-in.o fs/built-in.o ipc/built-in.o security/built-in.o crypto/built-in.o block/built-in.o lib/lib.a arch/sparc/prom/lib.a arch/sparc/lib/lib.a lib/built-in.o arch/sparc/prom/built-in.o arch/sparc/lib/built-in.o drivers/built-in.o sound/built-in.o net/built-in.o --end-group .tmp_kallsyms3.o arch/sparc/boot/btfix.o -o arch/sparc/boot/image
> .tmp_kallsyms3.o: In function `kallsyms_addresses':
> .tmp_kallsyms3.S:(.rodata+0x0): relocation truncated to fit: R_SPARC_32 against symbol `_text' defined in .text section in arch/sparc/boot/image
> .tmp_kallsyms3.S:(.rodata+0x8): relocation truncated to fit: R_SPARC_32 against symbol `_text' defined in .text section in arch/sparc/boot/image
> ...
> .tmp_kallsyms3.S:(.rodata+0x2c): additional relocation overflows omitted
> from the output
> make[2]: *** [arch/sparc/boot/image] Error 1
>
>
> arch/sparc/kernel/vmlinux.lds
> ...
> OUTPUT_FORMAT("elf32-sparc", "elf32-sparc", "elf32-sparc")
> OUTPUT_ARCH(sparc)
> ENTRY(_start)
> jiffies = jiffies_64 + 4;
> SECTIONS
> {
> . = 0x10000 + SIZEOF_HEADERS;
> .text 0xf0004000 :
> {
> _text = .;
> *(.text)
> . = ALIGN(8); __sched_text_start = .; *(.sched.text) __sched_text_end = .;
> . = ALIGN(8); __lock_text_start = .; *(.spinlock.text) __lock_text_end = .;
> *(.gnu.warning)
> } =0
> _etext = .;
> ...
>
>
> A look at .tmp_kallsyms3.S, symbol kallsyms_addresses which seems to cause
> linking error on sparc :
>
>
> #include <asm/types.h>
> #if BITS_PER_LONG = 64
> #define PTR .quad
> #define ALGN .align 8
> #else
> #define PTR .long
> #define ALGN .align 4
> #endif
> .section .rodata, "a"
> .globl kallsyms_addresses
> ALGN
> kallsyms_addresses:
> PTR _text - 0xeffd7000
> PTR 0x2d000
> PTR _text - 0xeffd6fb8
> PTR _text - 0xeffd6f50
> PTR _text - 0xeffd6ed0
> PTR _text - 0xeffd6eac
> PTR _text - 0xeffd6b84
> PTR _text - 0xeffd6860
> PTR _text - 0xeffd6830
> PTR _text - 0xeffd6814
> PTR _text - 0xeffd6794
> PTR _text - 0xeffd6788
> PTR _text - 0xeffd6778
> PTR _text - 0xeffd6764
> PTR _text - 0xeffd673c
> PTR _text - 0xeffd6714
> PTR _text - 0xeffd66e4
> PTR _text - 0xeffd66b4
> PTR _text - 0xeffd66ac
> PTR _text - 0xeffd6698
> PTR _text - 0xeffd6674
> PTR _text - 0xeffd6650
> PTR _text - 0xeffd63dc
> PTR _text - 0xeffd637c
> PTR _text - 0xeffd6304
> PTR _text - 0xeffd6060
> PTR _text - 0xeffd6034
> PTR _text - 0xeffd6008
> PTR _text - 0xeffd5ff8
> .....
>
> PTR _text - 0xeffbc7a0
> PTR _text - 0xeffbc730
> PTR 0x47930
> PTR _text + 0
> PTR _text + 0
> PTR _text + 0
> PTR _text + 0
> PTR _text + 0
> PTR _text + 0
> PTR _text + 0
> PTR _text + 0x10
> PTR _text + 0x20
> PTR _text + 0x30
> PTR _text + 0x40
> PTR _text + 0x50
> PTR _text + 0x60
> PTR _text + 0x70
> PTR _text + 0x80
> PTR _text + 0x90
> PTR _text + 0xa0
> PTR _text + 0xb0
> PTR _text + 0xc0
> PTR _text + 0x110
> PTR _text + 0x120
> PTR _text + 0x130
> PTR _text + 0x140
> PTR _text + 0x150
> ....
>
>
> PTR _text + 0x1b67c4
> PTR _text + 0x1b67d8
> PTR 0xf01ba890
>
>
> And by the way, I also add my own section to
> include/asm-generic/vmlinux.lds.h in RODATA :
> adds at line 124, kernel 2.6.20 :
> /* Kernel markers : pointers */ \
> .markers : AT(ADDR(.markers) - LOAD_OFFSET) { \
> VMLINUX_SYMBOL(__start___markers) = .; \
> *(.markers) \
> VMLINUX_SYMBOL(__stop___markers) = .; \
> } \
>
>
>
> --
> Mathieu Desnoyers
> Computer Engineering Graduate Student, École Polytechnique de Montréal
> OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
> _______________________________________________
> Ltt-dev mailing list
> Ltt-dev@listserv.shafik.org
> http://listserv.shafik.org/mailman/listinfo/ltt-dev
>
--
Mathieu Desnoyers
Computer Engineering Graduate Student, École Polytechnique de Montréal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Ltt-dev] Linux Kernel Markers : sparc build issue
2007-02-07 17:19 [Ltt-dev] Linux Kernel Markers : sparc build issue Mathieu Desnoyers
@ 2007-02-07 18:46 ` Mathieu Desnoyers
2007-02-07 19:30 ` Frank Ch. Eigler
` (3 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: Mathieu Desnoyers @ 2007-02-07 18:46 UTC (permalink / raw)
To: sparclinux
This issue is "fixed" by disabling KALLSYMS when building the kernel. I
added the following information in the menus :
config MARKERS
bool "Activate markers"
select MODULES
default n
help
Place an empty function call at each marker site. Can be
dynamically changed for a probe function.
Note that on sparc32, m68k and RS/6000, you may have to disable
kallsyms (under Configure standard kernel features (for small
systems), "Load all symbols for debugging/ksymoops") because of
a GOT size limit of respectively : 8k, 32k and 32k. It can
otherwise cause linking errors when too much markers appear in
the code.
Mathieu
* Mathieu Desnoyers (mathieu.desnoyers@polymtl.ca) wrote:
> It seems like I bust the 8k limit for the sparc GOT :
>
> The kallsyms_addresses is 8614 lines long (for a 33.6kB total) in the .S,
> and, according to
> http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/Code-Gen-Options.html :
>
> "If the GOT size for the linked executable exceeds a machine-specific
> maximum size, you get an error message from the linker indicating that
> -fpic does not work; in that case, recompile with -fPIC instead. (These
> maximums are 8k on the SPARC and 32k on the m68k and RS/6000. The 386
> has no such limit.)"
>
> Mathieu
>
>
> * Mathieu Desnoyers (mathieu.desnoyers@polymtl.ca) wrote:
> > * Frank Ch. Eigler (fche@redhat.com) wrote:
> > >
> > > Perhaps you could post excerpts of "objdump -dr <file.o>", to see the
> > > disassembly / relocations in question.
> > >
> > > - FChE
> >
> > Hi Frank,
> >
> > (this message follow up on
> > http://listserv.shafik.org/pipermail/ltt-dev/2007-February/002212.html)
> >
> > compudj@amd64:~/obj/sparc$ PATH=/opt/crosstool/gcc-4.1.1-glibc-2.3.6/sparc-unknown-linux-gnu/bin sparc-unknown-linux-gnu-objdump -dr .tmp_kallsyms3.o
> >
> > .tmp_kallsyms3.o: file format elf32-sparc
> >
> > (that's all)
> >
> > By looking at what follows in more depth, it looks like the symbols I
> > keep are relative to the beginning of the _text section and sparc would
> > have a limit regarding this (maximum offset ? number of offsets relative
> > to a symbol ?)
> >
> > Any insights are welcome,
> >
> > Mathieu
> >
> >
> > link error :
> >
> > opt/crosstool/gcc-4.1.1-glibc-2.3.6/sparc-unknown-linux-gnu/bin/sparc-unknown-linux-gnu-ld -m elf32_sparc -T arch/sparc/kernel/vmlinux.lds arch/sparc/kernel/head.o arch/sparc/kernel/init_task.o init/built-in.o --start-group usr/built-in.o arch/sparc/kernel/built-in.o arch/sparc/mm/built-in.o arch/sparc/math-emu/built-in.o kernel/built-in.o mm/built-in.o fs/built-in.o ipc/built-in.o security/built-in.o crypto/built-in.o block/built-in.o lib/lib.a arch/sparc/prom/lib.a arch/sparc/lib/lib.a lib/built-in.o arch/sparc/prom/built-in.o arch/sparc/lib/built-in.o drivers/built-in.o sound/built-in.o net/built-in.o --end-group .tmp_kallsyms3.o arch/sparc/boot/btfix.o -o arch/sparc/boot/image
> > .tmp_kallsyms3.o: In function `kallsyms_addresses':
> > .tmp_kallsyms3.S:(.rodata+0x0): relocation truncated to fit: R_SPARC_32 against symbol `_text' defined in .text section in arch/sparc/boot/image
> > .tmp_kallsyms3.S:(.rodata+0x8): relocation truncated to fit: R_SPARC_32 against symbol `_text' defined in .text section in arch/sparc/boot/image
> > ...
> > .tmp_kallsyms3.S:(.rodata+0x2c): additional relocation overflows omitted
> > from the output
> > make[2]: *** [arch/sparc/boot/image] Error 1
> >
> >
> > arch/sparc/kernel/vmlinux.lds
> > ...
> > OUTPUT_FORMAT("elf32-sparc", "elf32-sparc", "elf32-sparc")
> > OUTPUT_ARCH(sparc)
> > ENTRY(_start)
> > jiffies = jiffies_64 + 4;
> > SECTIONS
> > {
> > . = 0x10000 + SIZEOF_HEADERS;
> > .text 0xf0004000 :
> > {
> > _text = .;
> > *(.text)
> > . = ALIGN(8); __sched_text_start = .; *(.sched.text) __sched_text_end = .;
> > . = ALIGN(8); __lock_text_start = .; *(.spinlock.text) __lock_text_end = .;
> > *(.gnu.warning)
> > } =0
> > _etext = .;
> > ...
> >
> >
> > A look at .tmp_kallsyms3.S, symbol kallsyms_addresses which seems to cause
> > linking error on sparc :
> >
> >
> > #include <asm/types.h>
> > #if BITS_PER_LONG = 64
> > #define PTR .quad
> > #define ALGN .align 8
> > #else
> > #define PTR .long
> > #define ALGN .align 4
> > #endif
> > .section .rodata, "a"
> > .globl kallsyms_addresses
> > ALGN
> > kallsyms_addresses:
> > PTR _text - 0xeffd7000
> > PTR 0x2d000
> > PTR _text - 0xeffd6fb8
> > PTR _text - 0xeffd6f50
> > PTR _text - 0xeffd6ed0
> > PTR _text - 0xeffd6eac
> > PTR _text - 0xeffd6b84
> > PTR _text - 0xeffd6860
> > PTR _text - 0xeffd6830
> > PTR _text - 0xeffd6814
> > PTR _text - 0xeffd6794
> > PTR _text - 0xeffd6788
> > PTR _text - 0xeffd6778
> > PTR _text - 0xeffd6764
> > PTR _text - 0xeffd673c
> > PTR _text - 0xeffd6714
> > PTR _text - 0xeffd66e4
> > PTR _text - 0xeffd66b4
> > PTR _text - 0xeffd66ac
> > PTR _text - 0xeffd6698
> > PTR _text - 0xeffd6674
> > PTR _text - 0xeffd6650
> > PTR _text - 0xeffd63dc
> > PTR _text - 0xeffd637c
> > PTR _text - 0xeffd6304
> > PTR _text - 0xeffd6060
> > PTR _text - 0xeffd6034
> > PTR _text - 0xeffd6008
> > PTR _text - 0xeffd5ff8
> > .....
> >
> > PTR _text - 0xeffbc7a0
> > PTR _text - 0xeffbc730
> > PTR 0x47930
> > PTR _text + 0
> > PTR _text + 0
> > PTR _text + 0
> > PTR _text + 0
> > PTR _text + 0
> > PTR _text + 0
> > PTR _text + 0
> > PTR _text + 0x10
> > PTR _text + 0x20
> > PTR _text + 0x30
> > PTR _text + 0x40
> > PTR _text + 0x50
> > PTR _text + 0x60
> > PTR _text + 0x70
> > PTR _text + 0x80
> > PTR _text + 0x90
> > PTR _text + 0xa0
> > PTR _text + 0xb0
> > PTR _text + 0xc0
> > PTR _text + 0x110
> > PTR _text + 0x120
> > PTR _text + 0x130
> > PTR _text + 0x140
> > PTR _text + 0x150
> > ....
> >
> >
> > PTR _text + 0x1b67c4
> > PTR _text + 0x1b67d8
> > PTR 0xf01ba890
> >
> >
> > And by the way, I also add my own section to
> > include/asm-generic/vmlinux.lds.h in RODATA :
> > adds at line 124, kernel 2.6.20 :
> > /* Kernel markers : pointers */ \
> > .markers : AT(ADDR(.markers) - LOAD_OFFSET) { \
> > VMLINUX_SYMBOL(__start___markers) = .; \
> > *(.markers) \
> > VMLINUX_SYMBOL(__stop___markers) = .; \
> > } \
> >
> >
> >
> > --
> > Mathieu Desnoyers
> > Computer Engineering Graduate Student, École Polytechnique de Montréal
> > OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
> > _______________________________________________
> > Ltt-dev mailing list
> > Ltt-dev@listserv.shafik.org
> > http://listserv.shafik.org/mailman/listinfo/ltt-dev
> >
>
> --
> Mathieu Desnoyers
> Computer Engineering Graduate Student, École Polytechnique de Montréal
> OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
> _______________________________________________
> Ltt-dev mailing list
> Ltt-dev@listserv.shafik.org
> http://listserv.shafik.org/mailman/listinfo/ltt-dev
>
--
Mathieu Desnoyers
Computer Engineering Graduate Student, École Polytechnique de Montréal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Ltt-dev] Linux Kernel Markers : sparc build issue
2007-02-07 17:19 [Ltt-dev] Linux Kernel Markers : sparc build issue Mathieu Desnoyers
2007-02-07 18:46 ` Mathieu Desnoyers
@ 2007-02-07 19:30 ` Frank Ch. Eigler
2007-02-07 20:03 ` Mathieu Desnoyers
` (2 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: Frank Ch. Eigler @ 2007-02-07 19:30 UTC (permalink / raw)
To: sparclinux
Hi -
> It seems like I bust the 8k limit for the sparc GOT :
> The kallsyms_addresses is 8614 lines long (for a 33.6kB total) in the .S,
> and, according to
> http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/Code-Gen-Options.html :
> [...]
That could be it, but I don't see how that table of symbol addresses
.long _text - 0xbeef
is using any GOT slots at all. (Plus I don't know how a R_SPARC_32
could ever be truncated - maybe there is a 64- vs 32-bit toolchain
confusion happening somewhere?)
I could be misunderstanding things, but maybe what's wrong is that the
new markers section is located in a sensitive spot, and its size is
causing something else to no longer be reachable by shorter offsets.
What are the neighbouring regions in the linker script?
- FChE
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Ltt-dev] Linux Kernel Markers : sparc build issue
2007-02-07 17:19 [Ltt-dev] Linux Kernel Markers : sparc build issue Mathieu Desnoyers
2007-02-07 18:46 ` Mathieu Desnoyers
2007-02-07 19:30 ` Frank Ch. Eigler
@ 2007-02-07 20:03 ` Mathieu Desnoyers
2007-02-07 20:21 ` Mathieu Desnoyers
2007-02-07 20:32 ` Mathieu Desnoyers
4 siblings, 0 replies; 6+ messages in thread
From: Mathieu Desnoyers @ 2007-02-07 20:03 UTC (permalink / raw)
To: sparclinux
* Frank Ch. Eigler (fche@redhat.com) wrote:
> Hi -
>
> > It seems like I bust the 8k limit for the sparc GOT :
> > The kallsyms_addresses is 8614 lines long (for a 33.6kB total) in the .S,
> > and, according to
> > http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/Code-Gen-Options.html :
> > [...]
>
> That could be it, but I don't see how that table of symbol addresses
> .long _text - 0xbeef
> is using any GOT slots at all. (Plus I don't know how a R_SPARC_32
> could ever be truncated - maybe there is a 64- vs 32-bit toolchain
> confusion happening somewhere?)
>
The toolchain is built using crosstool 0.43 (plus modifications to get gcc
4.1.1). The target is sparc-unknown-linux-gnu (not sparc64-unknown-linux-gnu),
which seems correct.
I just found this post which is enlightening :
http://gcc.gnu.org/ml/gcc-bugs/2001-06/msg00115.html
"> > ld.so.1: ./a.out: fatal: relocation error: R_SPARC_32: file
/local/nathan/devel/lib/libstdc++.so.3: symbol __gxx_personality_v0:
offset 0x7fb1b0ca is non-aligned
>
> Until recently GNU binutils didn't handle R_SPARC_UA32 correctly. Try
> the
> native Solaris as/ld or a new snapshot.
I can confirm that the 010604 binutils snapshot is ok."
> I could be misunderstanding things, but maybe what's wrong is that the
> new markers section is located in a sensitive spot, and its size is
> causing something else to no longer be reachable by shorter offsets.
But if offsets are encoded on 32 bits, I don't see how it can become
unreachable. Unless it's a binutils bug..
I will try a different binutils version and keep you informed.
Mathieu
> What are the neighbouring regions in the linker script?
>
Here is the detail of arch/sparc/kernel/vmlinux.lds :
/* ld script to make SparcLinux kernel */
/* Align . to a 8 byte boundary equals to maximum function alignment. */
/* sched.text is aling to function alignment to secure we have same
* address even at second ld pass when generating System.map */
/* spinlock.text is aling to function alignment to secure we have same
* address even at second ld pass when generating System.map */
/* DWARF debug sections.
Symbols in the DWARF debugging sections are relative to
the beginning of the section so we begin them at 0. */
/* Stabs debugging sections. */
OUTPUT_FORMAT("elf32-sparc", "elf32-sparc", "elf32-sparc")
OUTPUT_ARCH(sparc)
ENTRY(_start)
jiffies = jiffies_64 + 4;
SECTIONS
{
. = 0x10000 + SIZEOF_HEADERS;
.text 0xf0004000 :
{
_text = .;
*(.text)
. = ALIGN(8); __sched_text_start = .; *(.sched.text) __sched_text_end = .;
. = ALIGN(8); __lock_text_start = .; *(.spinlock.text) __lock_text_end = .;
*(.gnu.warning)
} =0
_etext = .;
PROVIDE (etext = .);
. = ALIGN(4096); .rodata : AT(ADDR(.rodata) - 0) { __start_rodata = .; *(.rodata) *(.rodata.*) *(__vermagic) } .rodata1 : AT(ADDR(.rodata1) - 0) { *(.rodata1) } .pci_fixup : AT(ADDR(.pci_fixup) - 0) { __start_pci_fixups_early = .; *(.pci_fixup_early) __end_pci_fixups_early = .; __start_pci_fixups_header = .; *(.pci_fixup_header) __end_pci_fixups_header = .; __start_pci_fixups_final = .; *(.pci_fixup_final) __end_pci_fixups_final = .; __start_pci_fixups_enable = .; *(.pci_fixup_enable) __end_pci_fixups_enable = .; __start_pci_fixups_resume = .; *(.pci_fixup_resume) __end_pci_fixups_resume = .; } .rio_route : AT(ADDR(.rio_route) - 0) { __start_rio_route_ops = .; *(.rio_route_ops) __end_rio_route_ops = .; } __ksymtab : AT(ADDR(__ksymtab) - 0) { __start___ksymtab = .; *(__ksymtab) __stop___ksymtab = .; } __ksymtab_gpl : AT(ADDR(__ksymtab_gpl) - 0) { __start___ksymtab_gpl = .; *(__ksymtab_gpl) __stop___ksymtab_gpl = .; } __ksymtab_unused : AT(ADDR(__ksymtab_unused) - 0) { __start___ksymtab_unused = .; *(__ksymtab_unused) __stop___ksymtab_unused = .; } __ksymtab_unused_gpl : AT(ADDR(__ksymtab_unused_gpl) - 0) { __start___ksymtab_unused_gpl = .; *(__ksymtab_unused_gpl) __stop___ksymtab_unused_gpl = .; } __ksymtab_gpl_future : AT(ADDR(__ksymtab_gpl_future) - 0) { __start___ksymtab_gpl_future = .; *(__ksymtab_gpl_future) __stop___ksymtab_gpl_future = .; } __kcrctab : AT(ADDR(__kcrctab) - 0) { __start___kcrctab = .; *(__kcrctab) __stop___kcrctab = .; } __kcrctab_gpl : AT(ADDR(__kcrctab_gpl) - 0) { __start___kcrctab_gpl = .; *(__kcrctab_gpl) __stop___kcrctab_gpl = .; } __kcrctab_unused : AT(ADDR(__kcrctab_unused) - 0) { __start___kcrctab_unused = .; *(__kcrctab_unused) __stop___kcrctab_unused = .; } __kcrctab_unused_gpl : AT(ADDR(__kcrctab_unused_gpl) - 0) { __start___kcrctab_unused_gpl = .; *(__kcrctab_unused_gpl) __stop___kcrctab_unused_gpl = .; } __kcrctab_gpl_future : AT(ADDR(__kcrctab_gpl_future) - 0) { __start___kcrctab_gpl_future = .; *(__kcrctab_gpl_future) __stop___kcrctab_gpl_future = .; } __ksymtab_strings : A
T(ADDR(__ksymtab_strings) - 0) { *(__ksymtab_strings) } .markers : AT(ADDR(.markers) - 0) { __start___markers = .; *(.markers) __stop___markers = .; } __end_rodata = .; . = ALIGN(4096); __param : AT(ADDR(__param) - 0) { __start___param = .; *(__param) __stop___param = .; __end_rodata = .; } . = ALIGN(4096);
.data :
{
*(.data)
CONSTRUCTORS
}
.data1 : { *(.data1) }
_edata = .;
PROVIDE (edata = .);
__start___fixup = .;
.fixup : { *(.fixup) }
__stop___fixup = .;
__start___ex_table = .;
__ex_table : { *(__ex_table) }
__stop___ex_table = .;
. = ALIGN(4096);
__init_begin = .;
_sinittext = .;
.init.text : {
*(.init.text)
}
_einittext = .;
__init_text_end = .;
.init.data : { *(.init.data) }
. = ALIGN(16);
__setup_start = .;
.init.setup : { *(.init.setup) }
__setup_end = .;
__initcall_start = .;
.initcall.init : {
*(.initcall0.init) *(.initcall0s.init) *(.initcall1.init) *(.initcall1s.init) *(.initcall2.init) *(.initcall2s.init) *(.initcall3.init) *(.initcall3s.init) *(.initcall4.init) *(.initcall4s.init) *(.initcall5.init) *(.initcall5s.init) *(.initcallrootfs.init) *(.initcall6.init) *(.initcall6s.init) *(.initcall7.init) *(.initcall7s.init)
}
__initcall_end = .;
__con_initcall_start = .;
.con_initcall.init : { *(.con_initcall.init) }
__con_initcall_end = .;
.security_initcall.init : AT(ADDR(.security_initcall.init) - 0) { __security_initcall_start = .; *(.security_initcall.init) __security_initcall_end = .; }
. = ALIGN(4096);
__initramfs_start = .;
.init.ramfs : { *(.init.ramfs) }
__initramfs_end = .;
. = ALIGN(32);
__per_cpu_start = .;
.data.percpu : { *(.data.percpu) }
__per_cpu_end = .;
. = ALIGN(4096);
__init_end = .;
. = ALIGN(32);
.data.cacheline_aligned : { *(.data.cacheline_aligned) }
__bss_start = .;
.sbss : { *(.sbss) *(.scommon) }
.bss :
{
*(.dynbss)
*(.bss)
*(COMMON)
}
_end = . ;
PROVIDE (end = .);
/DISCARD/ : { *(.exit.text) *(.exit.data) *(.exitcall.exit) }
.stab 0 : { *(.stab) } .stabstr 0 : { *(.stabstr) } .stab.excl 0 : { *(.stab.excl) } .stab.exclstr 0 : { *(.stab.exclstr) } .stab.index 0 : { *(.stab.index) } .stab.indexstr 0 : { *(.stab.indexstr) } .comment 0 : { *(.comment) }
.debug 0 : { *(.debug) } .line 0 : { *(.line) } .debug_srcinfo 0 : { *(.debug_srcinfo) } .debug_sfnames 0 : { *(.debug_sfnames) } .debug_aranges 0 : { *(.debug_aranges) } .debug_pubnames 0 : { *(.debug_pubnames) } .debug_info 0 : { *(.debug_info .gnu.linkonce.wi.*) } .debug_abbrev 0 : { *(.debug_abbrev) } .debug_line 0 : { *(.debug_line) } .debug_frame 0 : { *(.debug_frame) } .debug_str 0 : { *(.debug_str) } .debug_loc 0 : { *(.debug_loc) } .debug_macinfo 0 : { *(.debug_macinfo) } .debug_weaknames 0 : { *(.debug_weaknames) } .debug_funcnames 0 : { *(.debug_funcnames) } .debug_typenames 0 : { *(.debug_typenames) } .debug_varnames 0 : { *(.debug_varnames) }
}
--
Mathieu Desnoyers
Computer Engineering Graduate Student, École Polytechnique de Montréal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Ltt-dev] Linux Kernel Markers : sparc build issue
2007-02-07 17:19 [Ltt-dev] Linux Kernel Markers : sparc build issue Mathieu Desnoyers
` (2 preceding siblings ...)
2007-02-07 20:03 ` Mathieu Desnoyers
@ 2007-02-07 20:21 ` Mathieu Desnoyers
2007-02-07 20:32 ` Mathieu Desnoyers
4 siblings, 0 replies; 6+ messages in thread
From: Mathieu Desnoyers @ 2007-02-07 20:21 UTC (permalink / raw)
To: sparclinux
It may be related :
PATH=/opt/crosstool/gcc-4.1.1-glibc-2.3.6/sparc-unknown-linux-gnu/bin \
sparc-unknown-linux-gnu-objdump -r vmlinux
RELOCATION RECORDS FOR [.markers.c]:
OFFSET TYPE VALUE
00000000 R_SPARC_UA32 .rodata+0x00029d98
00000004 R_SPARC_UA32 .data+0x00002558
00000008 R_SPARC_UA32 .rodata+0x00029d08
00000010 R_SPARC_UA32 .rodata+0x00029db0
00000014 R_SPARC_UA32 .data+0x0000255c
00000018 R_SPARC_UA32 .rodata+0x00029d70
00000020 R_SPARC_UA32 .rodata+0x00029dc8
00000024 R_SPARC_UA32 .data+0x00002560
00000028 R_SPARC_UA32 .rodata+0x00029d08
00000030 R_SPARC_UA32 .rodata+0x00029f00
....
the .markers.c seems to have unaligned relocation records, which is a
little odd. I don't see other elsewhere in vmlinux.
Mathieu
* Mathieu Desnoyers (compudj@krystal.dyndns.org) wrote:
> * Frank Ch. Eigler (fche@redhat.com) wrote:
> > Hi -
> >
> > > It seems like I bust the 8k limit for the sparc GOT :
> > > The kallsyms_addresses is 8614 lines long (for a 33.6kB total) in the .S,
> > > and, according to
> > > http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/Code-Gen-Options.html :
> > > [...]
> >
> > That could be it, but I don't see how that table of symbol addresses
> > .long _text - 0xbeef
> > is using any GOT slots at all. (Plus I don't know how a R_SPARC_32
> > could ever be truncated - maybe there is a 64- vs 32-bit toolchain
> > confusion happening somewhere?)
> >
>
> The toolchain is built using crosstool 0.43 (plus modifications to get gcc
> 4.1.1). The target is sparc-unknown-linux-gnu (not sparc64-unknown-linux-gnu),
> which seems correct.
>
> I just found this post which is enlightening :
> http://gcc.gnu.org/ml/gcc-bugs/2001-06/msg00115.html
> "> > ld.so.1: ./a.out: fatal: relocation error: R_SPARC_32: file
> /local/nathan/devel/lib/libstdc++.so.3: symbol __gxx_personality_v0:
> offset 0x7fb1b0ca is non-aligned
> >
> > Until recently GNU binutils didn't handle R_SPARC_UA32 correctly. Try
> > the
> > native Solaris as/ld or a new snapshot.
> I can confirm that the 010604 binutils snapshot is ok."
>
>
> > I could be misunderstanding things, but maybe what's wrong is that the
> > new markers section is located in a sensitive spot, and its size is
> > causing something else to no longer be reachable by shorter offsets.
>
> But if offsets are encoded on 32 bits, I don't see how it can become
> unreachable. Unless it's a binutils bug..
>
> I will try a different binutils version and keep you informed.
>
> Mathieu
>
> > What are the neighbouring regions in the linker script?
> >
>
> Here is the detail of arch/sparc/kernel/vmlinux.lds :
>
> /* ld script to make SparcLinux kernel */
> /* Align . to a 8 byte boundary equals to maximum function alignment. */
> /* sched.text is aling to function alignment to secure we have same
> * address even at second ld pass when generating System.map */
> /* spinlock.text is aling to function alignment to secure we have same
> * address even at second ld pass when generating System.map */
> /* DWARF debug sections.
> Symbols in the DWARF debugging sections are relative to
> the beginning of the section so we begin them at 0. */
> /* Stabs debugging sections. */
> OUTPUT_FORMAT("elf32-sparc", "elf32-sparc", "elf32-sparc")
> OUTPUT_ARCH(sparc)
> ENTRY(_start)
> jiffies = jiffies_64 + 4;
> SECTIONS
> {
> . = 0x10000 + SIZEOF_HEADERS;
> .text 0xf0004000 :
> {
> _text = .;
> *(.text)
> . = ALIGN(8); __sched_text_start = .; *(.sched.text) __sched_text_end = .;
> . = ALIGN(8); __lock_text_start = .; *(.spinlock.text) __lock_text_end = .;
> *(.gnu.warning)
> } =0
> _etext = .;
> PROVIDE (etext = .);
> . = ALIGN(4096); .rodata : AT(ADDR(.rodata) - 0) { __start_rodata = .; *(.rodata) *(.rodata.*) *(__vermagic) } .rodata1 : AT(ADDR(.rodata1) - 0) { *(.rodata1) } .pci_fixup : AT(ADDR(.pci_fixup) - 0) { __start_pci_fixups_early = .; *(.pci_fixup_early) __end_pci_fixups_early = .; __start_pci_fixups_header = .; *(.pci_fixup_header) __end_pci_fixups_header = .; __start_pci_fixups_final = .; *(.pci_fixup_final) __end_pci_fixups_final = .; __start_pci_fixups_enable = .; *(.pci_fixup_enable) __end_pci_fixups_enable = .; __start_pci_fixups_resume = .; *(.pci_fixup_resume) __end_pci_fixups_resume = .; } .rio_route : AT(ADDR(.rio_route) - 0) { __start_rio_route_ops = .; *(.rio_route_ops) __end_rio_route_ops = .; } __ksymtab : AT(ADDR(__ksymtab) - 0) { __start___ksymtab = .; *(__ksymtab) __stop___ksymtab = .; } __ksymtab_gpl : AT(ADDR(__ksymtab_gpl) - 0) { __start___ksymtab_gpl = .; *(__ksymtab_gpl) __stop___ksymtab_gpl = .; } __ksymtab_unused : AT(ADDR(__ksymtab_unused) - 0) { __start___ksymtab_unused = .; *(__ksymtab_unused) __stop___ksymtab_unused = .; } __ksymtab_unused_gpl : AT(ADDR(__ksymtab_unused_gpl) - 0) { __start___ksymtab_unused_gpl = .; *(__ksymtab_unused_gpl) __stop___ksymtab_unused_gpl = .; } __ksymtab_gpl_future : AT(ADDR(__ksymtab_gpl_future) - 0) { __start___ksymtab_gpl_future = .; *(__ksymtab_gpl_future) __stop___ksymtab_gpl_future = .; } __kcrctab : AT(ADDR(__kcrctab) - 0) { __start___kcrctab = .; *(__kcrctab) __stop___kcrctab = .; } __kcrctab_gpl : AT(ADDR(__kcrctab_gpl) - 0) { __start___kcrctab_gpl = .; *(__kcrctab_gpl) __stop___kcrctab_gpl = .; } __kcrctab_unused : AT(ADDR(__kcrctab_unused) - 0) { __start___kcrctab_unused = .; *(__kcrctab_unused) __stop___kcrctab_unused = .; } __kcrctab_unused_gpl : AT(ADDR(__kcrctab_unused_gpl) - 0) { __start___kcrctab_unused_gpl = .; *(__kcrctab_unused_gpl) __stop___kcrctab_unused_gpl = .; } __kcrctab_gpl_future : AT(ADDR(__kcrctab_gpl_future) - 0) { __start___kcrctab_gpl_future = .; *(__kcrctab_gpl_future) __stop___kcrctab_gpl_future = .; } __ksymtab_strings :
AT(ADDR(__ksymtab_strings) - 0) { *(__ksymtab_strings) } .markers : AT(ADDR(.markers) - 0) { __start___markers = .; *(.markers) __stop___markers = .; } __end_rodata = .; . = ALIGN(4096); __param : AT(ADDR(__param) - 0) { __start___param = .; *(__param) __stop___param = .; __end_rodata = .; } . = ALIGN(4096);
> .data :
> {
> *(.data)
> CONSTRUCTORS
> }
> .data1 : { *(.data1) }
> _edata = .;
> PROVIDE (edata = .);
> __start___fixup = .;
> .fixup : { *(.fixup) }
> __stop___fixup = .;
> __start___ex_table = .;
> __ex_table : { *(__ex_table) }
> __stop___ex_table = .;
> . = ALIGN(4096);
> __init_begin = .;
> _sinittext = .;
> .init.text : {
> *(.init.text)
> }
> _einittext = .;
> __init_text_end = .;
> .init.data : { *(.init.data) }
> . = ALIGN(16);
> __setup_start = .;
> .init.setup : { *(.init.setup) }
> __setup_end = .;
> __initcall_start = .;
> .initcall.init : {
> *(.initcall0.init) *(.initcall0s.init) *(.initcall1.init) *(.initcall1s.init) *(.initcall2.init) *(.initcall2s.init) *(.initcall3.init) *(.initcall3s.init) *(.initcall4.init) *(.initcall4s.init) *(.initcall5.init) *(.initcall5s.init) *(.initcallrootfs.init) *(.initcall6.init) *(.initcall6s.init) *(.initcall7.init) *(.initcall7s.init)
> }
> __initcall_end = .;
> __con_initcall_start = .;
> .con_initcall.init : { *(.con_initcall.init) }
> __con_initcall_end = .;
> .security_initcall.init : AT(ADDR(.security_initcall.init) - 0) { __security_initcall_start = .; *(.security_initcall.init) __security_initcall_end = .; }
> . = ALIGN(4096);
> __initramfs_start = .;
> .init.ramfs : { *(.init.ramfs) }
> __initramfs_end = .;
> . = ALIGN(32);
> __per_cpu_start = .;
> .data.percpu : { *(.data.percpu) }
> __per_cpu_end = .;
> . = ALIGN(4096);
> __init_end = .;
> . = ALIGN(32);
> .data.cacheline_aligned : { *(.data.cacheline_aligned) }
> __bss_start = .;
> .sbss : { *(.sbss) *(.scommon) }
> .bss :
> {
> *(.dynbss)
> *(.bss)
> *(COMMON)
> }
> _end = . ;
> PROVIDE (end = .);
> /DISCARD/ : { *(.exit.text) *(.exit.data) *(.exitcall.exit) }
> .stab 0 : { *(.stab) } .stabstr 0 : { *(.stabstr) } .stab.excl 0 : { *(.stab.excl) } .stab.exclstr 0 : { *(.stab.exclstr) } .stab.index 0 : { *(.stab.index) } .stab.indexstr 0 : { *(.stab.indexstr) } .comment 0 : { *(.comment) }
> .debug 0 : { *(.debug) } .line 0 : { *(.line) } .debug_srcinfo 0 : { *(.debug_srcinfo) } .debug_sfnames 0 : { *(.debug_sfnames) } .debug_aranges 0 : { *(.debug_aranges) } .debug_pubnames 0 : { *(.debug_pubnames) } .debug_info 0 : { *(.debug_info .gnu.linkonce.wi.*) } .debug_abbrev 0 : { *(.debug_abbrev) } .debug_line 0 : { *(.debug_line) } .debug_frame 0 : { *(.debug_frame) } .debug_str 0 : { *(.debug_str) } .debug_loc 0 : { *(.debug_loc) } .debug_macinfo 0 : { *(.debug_macinfo) } .debug_weaknames 0 : { *(.debug_weaknames) } .debug_funcnames 0 : { *(.debug_funcnames) } .debug_typenames 0 : { *(.debug_typenames) } .debug_varnames 0 : { *(.debug_varnames) }
> }
>
>
> --
> Mathieu Desnoyers
> Computer Engineering Graduate Student, École Polytechnique de Montréal
> OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
> _______________________________________________
> Ltt-dev mailing list
> Ltt-dev@listserv.shafik.org
> http://listserv.shafik.org/mailman/listinfo/ltt-dev
>
--
Mathieu Desnoyers
Computer Engineering Graduate Student, École Polytechnique de Montréal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Ltt-dev] Linux Kernel Markers : sparc build issue
2007-02-07 17:19 [Ltt-dev] Linux Kernel Markers : sparc build issue Mathieu Desnoyers
` (3 preceding siblings ...)
2007-02-07 20:21 ` Mathieu Desnoyers
@ 2007-02-07 20:32 ` Mathieu Desnoyers
4 siblings, 0 replies; 6+ messages in thread
From: Mathieu Desnoyers @ 2007-02-07 20:32 UTC (permalink / raw)
To: sparclinux
Bug found and solved :
I forgot to declare the section .markers.c in
include/asm-generic/vmlinux.lds.h, which caused it to be unaligned. Only
sparc's ld seemed to choke on such unaligned relocation information.
Thanks for your support :)
Mathieu
The fix :
diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index d299de2..7fa3d19 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -127,6 +127,11 @@
*(.markers) \
VMLINUX_SYMBOL(__stop___markers) = .; \
} \
+ .markers.c : AT(ADDR(.markers.c) - LOAD_OFFSET) { \
+ VMLINUX_SYMBOL(__start___markers_c) = .; \
+ *(.markers.c) \
+ VMLINUX_SYMBOL(__stop___markers_c) = .; \
+ } \
__end_rodata = .; \
. = ALIGN(4096); \
\
* Mathieu Desnoyers (compudj@krystal.dyndns.org) wrote:
> It may be related :
>
> PATH=/opt/crosstool/gcc-4.1.1-glibc-2.3.6/sparc-unknown-linux-gnu/bin \
> sparc-unknown-linux-gnu-objdump -r vmlinux
>
> RELOCATION RECORDS FOR [.markers.c]:
> OFFSET TYPE VALUE
> 00000000 R_SPARC_UA32 .rodata+0x00029d98
> 00000004 R_SPARC_UA32 .data+0x00002558
> 00000008 R_SPARC_UA32 .rodata+0x00029d08
> 00000010 R_SPARC_UA32 .rodata+0x00029db0
> 00000014 R_SPARC_UA32 .data+0x0000255c
> 00000018 R_SPARC_UA32 .rodata+0x00029d70
> 00000020 R_SPARC_UA32 .rodata+0x00029dc8
> 00000024 R_SPARC_UA32 .data+0x00002560
> 00000028 R_SPARC_UA32 .rodata+0x00029d08
> 00000030 R_SPARC_UA32 .rodata+0x00029f00
> ....
>
> the .markers.c seems to have unaligned relocation records, which is a
> little odd. I don't see other elsewhere in vmlinux.
>
> Mathieu
>
>
> * Mathieu Desnoyers (compudj@krystal.dyndns.org) wrote:
> > * Frank Ch. Eigler (fche@redhat.com) wrote:
> > > Hi -
> > >
> > > > It seems like I bust the 8k limit for the sparc GOT :
> > > > The kallsyms_addresses is 8614 lines long (for a 33.6kB total) in the .S,
> > > > and, according to
> > > > http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/Code-Gen-Options.html :
> > > > [...]
> > >
> > > That could be it, but I don't see how that table of symbol addresses
> > > .long _text - 0xbeef
> > > is using any GOT slots at all. (Plus I don't know how a R_SPARC_32
> > > could ever be truncated - maybe there is a 64- vs 32-bit toolchain
> > > confusion happening somewhere?)
> > >
> >
> > The toolchain is built using crosstool 0.43 (plus modifications to get gcc
> > 4.1.1). The target is sparc-unknown-linux-gnu (not sparc64-unknown-linux-gnu),
> > which seems correct.
> >
> > I just found this post which is enlightening :
> > http://gcc.gnu.org/ml/gcc-bugs/2001-06/msg00115.html
> > "> > ld.so.1: ./a.out: fatal: relocation error: R_SPARC_32: file
> > /local/nathan/devel/lib/libstdc++.so.3: symbol __gxx_personality_v0:
> > offset 0x7fb1b0ca is non-aligned
> > >
> > > Until recently GNU binutils didn't handle R_SPARC_UA32 correctly. Try
> > > the
> > > native Solaris as/ld or a new snapshot.
> > I can confirm that the 010604 binutils snapshot is ok."
> >
> >
> > > I could be misunderstanding things, but maybe what's wrong is that the
> > > new markers section is located in a sensitive spot, and its size is
> > > causing something else to no longer be reachable by shorter offsets.
> >
> > But if offsets are encoded on 32 bits, I don't see how it can become
> > unreachable. Unless it's a binutils bug..
> >
> > I will try a different binutils version and keep you informed.
> >
> > Mathieu
> >
> > > What are the neighbouring regions in the linker script?
> > >
> >
> > Here is the detail of arch/sparc/kernel/vmlinux.lds :
> >
> > /* ld script to make SparcLinux kernel */
> > /* Align . to a 8 byte boundary equals to maximum function alignment. */
> > /* sched.text is aling to function alignment to secure we have same
> > * address even at second ld pass when generating System.map */
> > /* spinlock.text is aling to function alignment to secure we have same
> > * address even at second ld pass when generating System.map */
> > /* DWARF debug sections.
> > Symbols in the DWARF debugging sections are relative to
> > the beginning of the section so we begin them at 0. */
> > /* Stabs debugging sections. */
> > OUTPUT_FORMAT("elf32-sparc", "elf32-sparc", "elf32-sparc")
> > OUTPUT_ARCH(sparc)
> > ENTRY(_start)
> > jiffies = jiffies_64 + 4;
> > SECTIONS
> > {
> > . = 0x10000 + SIZEOF_HEADERS;
> > .text 0xf0004000 :
> > {
> > _text = .;
> > *(.text)
> > . = ALIGN(8); __sched_text_start = .; *(.sched.text) __sched_text_end = .;
> > . = ALIGN(8); __lock_text_start = .; *(.spinlock.text) __lock_text_end = .;
> > *(.gnu.warning)
> > } =0
> > _etext = .;
> > PROVIDE (etext = .);
> > . = ALIGN(4096); .rodata : AT(ADDR(.rodata) - 0) { __start_rodata = .; *(.rodata) *(.rodata.*) *(__vermagic) } .rodata1 : AT(ADDR(.rodata1) - 0) { *(.rodata1) } .pci_fixup : AT(ADDR(.pci_fixup) - 0) { __start_pci_fixups_early = .; *(.pci_fixup_early) __end_pci_fixups_early = .; __start_pci_fixups_header = .; *(.pci_fixup_header) __end_pci_fixups_header = .; __start_pci_fixups_final = .; *(.pci_fixup_final) __end_pci_fixups_final = .; __start_pci_fixups_enable = .; *(.pci_fixup_enable) __end_pci_fixups_enable = .; __start_pci_fixups_resume = .; *(.pci_fixup_resume) __end_pci_fixups_resume = .; } .rio_route : AT(ADDR(.rio_route) - 0) { __start_rio_route_ops = .; *(.rio_route_ops) __end_rio_route_ops = .; } __ksymtab : AT(ADDR(__ksymtab) - 0) { __start___ksymtab = .; *(__ksymtab) __stop___ksymtab = .; } __ksymtab_gpl : AT(ADDR(__ksymtab_gpl) - 0) { __start___ksymtab_gpl = .; *(__ksymtab_gpl) __stop___ksymtab_gpl = .; } __ksymtab_unused : AT(ADDR(__ksymtab_unused) - 0) { __start___ksymtab_unused = .; *(__ksymtab_unused) __stop___ksymtab_unused = .; } __ksymtab_unused_gpl : AT(ADDR(__ksymtab_unused_gpl) - 0) { __start___ksymtab_unused_gpl = .; *(__ksymtab_unused_gpl) __stop___ksymtab_unused_gpl = .; } __ksymtab_gpl_future : AT(ADDR(__ksymtab_gpl_future) - 0) { __start___ksymtab_gpl_future = .; *(__ksymtab_gpl_future) __stop___ksymtab_gpl_future = .; } __kcrctab : AT(ADDR(__kcrctab) - 0) { __start___kcrctab = .; *(__kcrctab) __stop___kcrctab = .; } __kcrctab_gpl : AT(ADDR(__kcrctab_gpl) - 0) { __start___kcrctab_gpl = .; *(__kcrctab_gpl) __stop___kcrctab_gpl = .; } __kcrctab_unused : AT(ADDR(__kcrctab_unused) - 0) { __start___kcrctab_unused = .; *(__kcrctab_unused) __stop___kcrctab_unused = .; } __kcrctab_unused_gpl : AT(ADDR(__kcrctab_unused_gpl) - 0) { __start___kcrctab_unused_gpl = .; *(__kcrctab_unused_gpl) __stop___kcrctab_unused_gpl = .; } __kcrctab_gpl_future : AT(ADDR(__kcrctab_gpl_future) - 0) { __start___kcrctab_gpl_future = .; *(__kcrctab_gpl_future) __stop___kcrctab_gpl_future = .; } __ksymtab_strings
: AT(ADDR(__ksymtab_strings) - 0) { *(__ksymtab_strings) } .markers : AT(ADDR(.markers) - 0) { __start___markers = .; *(.markers) __stop___markers = .; } __end_rodata = .; . = ALIGN(4096); __param : AT(ADDR(__param) - 0) { __start___param = .; *(__param) __stop___param = .; __end_rodata = .; } . = ALIGN(4096);
> > .data :
> > {
> > *(.data)
> > CONSTRUCTORS
> > }
> > .data1 : { *(.data1) }
> > _edata = .;
> > PROVIDE (edata = .);
> > __start___fixup = .;
> > .fixup : { *(.fixup) }
> > __stop___fixup = .;
> > __start___ex_table = .;
> > __ex_table : { *(__ex_table) }
> > __stop___ex_table = .;
> > . = ALIGN(4096);
> > __init_begin = .;
> > _sinittext = .;
> > .init.text : {
> > *(.init.text)
> > }
> > _einittext = .;
> > __init_text_end = .;
> > .init.data : { *(.init.data) }
> > . = ALIGN(16);
> > __setup_start = .;
> > .init.setup : { *(.init.setup) }
> > __setup_end = .;
> > __initcall_start = .;
> > .initcall.init : {
> > *(.initcall0.init) *(.initcall0s.init) *(.initcall1.init) *(.initcall1s.init) *(.initcall2.init) *(.initcall2s.init) *(.initcall3.init) *(.initcall3s.init) *(.initcall4.init) *(.initcall4s.init) *(.initcall5.init) *(.initcall5s.init) *(.initcallrootfs.init) *(.initcall6.init) *(.initcall6s.init) *(.initcall7.init) *(.initcall7s.init)
> > }
> > __initcall_end = .;
> > __con_initcall_start = .;
> > .con_initcall.init : { *(.con_initcall.init) }
> > __con_initcall_end = .;
> > .security_initcall.init : AT(ADDR(.security_initcall.init) - 0) { __security_initcall_start = .; *(.security_initcall.init) __security_initcall_end = .; }
> > . = ALIGN(4096);
> > __initramfs_start = .;
> > .init.ramfs : { *(.init.ramfs) }
> > __initramfs_end = .;
> > . = ALIGN(32);
> > __per_cpu_start = .;
> > .data.percpu : { *(.data.percpu) }
> > __per_cpu_end = .;
> > . = ALIGN(4096);
> > __init_end = .;
> > . = ALIGN(32);
> > .data.cacheline_aligned : { *(.data.cacheline_aligned) }
> > __bss_start = .;
> > .sbss : { *(.sbss) *(.scommon) }
> > .bss :
> > {
> > *(.dynbss)
> > *(.bss)
> > *(COMMON)
> > }
> > _end = . ;
> > PROVIDE (end = .);
> > /DISCARD/ : { *(.exit.text) *(.exit.data) *(.exitcall.exit) }
> > .stab 0 : { *(.stab) } .stabstr 0 : { *(.stabstr) } .stab.excl 0 : { *(.stab.excl) } .stab.exclstr 0 : { *(.stab.exclstr) } .stab.index 0 : { *(.stab.index) } .stab.indexstr 0 : { *(.stab.indexstr) } .comment 0 : { *(.comment) }
> > .debug 0 : { *(.debug) } .line 0 : { *(.line) } .debug_srcinfo 0 : { *(.debug_srcinfo) } .debug_sfnames 0 : { *(.debug_sfnames) } .debug_aranges 0 : { *(.debug_aranges) } .debug_pubnames 0 : { *(.debug_pubnames) } .debug_info 0 : { *(.debug_info .gnu.linkonce.wi.*) } .debug_abbrev 0 : { *(.debug_abbrev) } .debug_line 0 : { *(.debug_line) } .debug_frame 0 : { *(.debug_frame) } .debug_str 0 : { *(.debug_str) } .debug_loc 0 : { *(.debug_loc) } .debug_macinfo 0 : { *(.debug_macinfo) } .debug_weaknames 0 : { *(.debug_weaknames) } .debug_funcnames 0 : { *(.debug_funcnames) } .debug_typenames 0 : { *(.debug_typenames) } .debug_varnames 0 : { *(.debug_varnames) }
> > }
> >
> >
> > --
> > Mathieu Desnoyers
> > Computer Engineering Graduate Student, École Polytechnique de Montréal
> > OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
> > _______________________________________________
> > Ltt-dev mailing list
> > Ltt-dev@listserv.shafik.org
> > http://listserv.shafik.org/mailman/listinfo/ltt-dev
> >
>
> --
> Mathieu Desnoyers
> Computer Engineering Graduate Student, École Polytechnique de Montréal
> OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
> _______________________________________________
> Ltt-dev mailing list
> Ltt-dev@listserv.shafik.org
> http://listserv.shafik.org/mailman/listinfo/ltt-dev
>
--
Mathieu Desnoyers
Computer Engineering Graduate Student, École Polytechnique de Montréal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
^ permalink raw reply related [flat|nested] 6+ messages in thread
end of thread, other threads:[~2007-02-07 20:32 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-02-07 17:19 [Ltt-dev] Linux Kernel Markers : sparc build issue Mathieu Desnoyers
2007-02-07 18:46 ` Mathieu Desnoyers
2007-02-07 19:30 ` Frank Ch. Eigler
2007-02-07 20:03 ` Mathieu Desnoyers
2007-02-07 20:21 ` Mathieu Desnoyers
2007-02-07 20:32 ` Mathieu Desnoyers
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.