From: Mathieu Desnoyers <compudj@krystal.dyndns.org>
To: sparclinux@vger.kernel.org
Subject: Re: [Ltt-dev] Linux Kernel Markers : sparc build issue
Date: Wed, 07 Feb 2007 20:32:26 +0000 [thread overview]
Message-ID: <20070207203225.GA19489@Krystal> (raw)
In-Reply-To: <20070207171912.GA5992@Krystal>
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
prev parent reply other threads:[~2007-02-07 20:32 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
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 message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070207203225.GA19489@Krystal \
--to=compudj@krystal.dyndns.org \
--cc=sparclinux@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.