Re: [XenPPC] [xenppc-unstable] [XEN][POWERPC] Linker script simplification broke optimized builds.
On Jan 23, 2007, at 12:22 PM, Segher Boessenkool wrote: Again -- do you have a testcase for the failure that made you revert this patch? yeah, gcc -O2 just build xen with debug=n, the symptom is that string literals got truncated.. LITERALLY! -JX ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] [xenppc-unstable] [XEN][POWERPC] Linker script simplification broke optimized builds.
the original script came from binutils and we simply adapted it. Yes, but that script is meant for userspace things and isn't the right thing for your environment. I tried to simplify but I was unable to predict all the gcc created sections for various gcc flags (esp -O2), so I just put all that stuff back. GCC won't create too many sections, just a few, unless you do something terribly wrong. I'll try another pass at another time, when I can test all scenarios. Good to hear. I consider this patch reversion to be a regression though. There is a huge degree of risk playing here, you can imagine how hard an issues from a dropped section would be hard to detect. I tend to fix such issues, they're not hard to detect at all (almost all of the time) -- dropped sections lead to hard crashes really easily ;-) Figuring out what is wrong is another thing -- often it is *not* the linker script but something else btw, you just get lucky with a certain script and a certain binutils version but unlucky with another combo. Perhaps ld has options to warn when badness occurs. Yeah it can do many of those things. Again -- do you have a testcase for the failure that made you revert this patch? Segher ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] [xenppc-unstable] [XEN][POWERPC] Linker script simplification broke optimized builds.
the original script came from binutils and we simply adapted it.
I tried to simplify but I was unable to predict all the gcc created
sections for various gcc flags (esp -O2), so I just put all that
stuff back.
I'll try another pass at another time, when I can test all scenarios.
There is a huge degree of risk playing here, you can imagine how hard
an issues from a dropped section would be hard to detect. Perhaps ld
has options to warn when badness occurs.
I got lucky with this one.
-JX
On Jan 23, 2007, at 3:51 AM, Segher Boessenkool wrote:
[XEN][POWERPC] Linker script simplification broke optimized builds.
offending changeset was: changeset: 14126:c759c733f77d
So put it back and just update the symbols like a good little boy.
What, you're replacing one bug by a big bag of other
bugs? Wouldn't it have been smarter to just fix the
bug you had? Is there any bug report about the original
problem (I didn't see it)?
+SEARCH_DIR("=/usr/local/lib64"); SEARCH_DIR("=/lib64"); SEARCH_DIR
("=/usr/lib64"); SEARCH_DIR("=/usr/local/lib"); SEARCH_DIR("=/
lib"); SEARCH_DIR("=/usr/lib");
For example, this obviously is very very wrong.
I don't dare look at the rest of this patch (well I
did, but I don't know where to start commenting on
it ;-) )
Segher
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] [xenppc-unstable] [XEN][POWERPC] Linker script simplification broke optimized builds.
[XEN][POWERPC] Linker script simplification broke optimized builds.
offending changeset was: changeset: 14126:c759c733f77d
So put it back and just update the symbols like a good little boy.
What, you're replacing one bug by a big bag of other
bugs? Wouldn't it have been smarter to just fix the
bug you had? Is there any bug report about the original
problem (I didn't see it)?
+SEARCH_DIR("=/usr/local/lib64"); SEARCH_DIR("=/lib64"); SEARCH_DIR
("=/usr/lib64"); SEARCH_DIR("=/usr/local/lib"); SEARCH_DIR("=/
lib"); SEARCH_DIR("=/usr/lib");
For example, this obviously is very very wrong.
I don't dare look at the rest of this patch (well I
did, but I don't know where to start commenting on
it ;-) )
Segher
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
[XenPPC] [xenppc-unstable] [XEN][POWERPC] Linker script simplification broke optimized builds.
# HG changeset patch
# User Jimi Xenidis <[EMAIL PROTECTED]>
# Node ID 8b7a8c2e0178f326cfef9fa01a5042a52503dacc
# Parent d301edbf6ecec86d24573e4be3399fbf3a4bd463
[XEN][POWERPC] Linker script simplification broke optimized builds.
offending changeset was: changeset: 14126:c759c733f77d
So put it back and just update the symbols like a good little boy.
Signed-off-by: Jimi Xenidis <[EMAIL PROTECTED]>
---
xen/arch/powerpc/xen.lds.S | 182 ++---
1 files changed, 141 insertions(+), 41 deletions(-)
diff -r d301edbf6ece -r 8b7a8c2e0178 xen/arch/powerpc/xen.lds.S
--- a/xen/arch/powerpc/xen.lds.SMon Jan 22 13:01:31 2007 -0500
+++ b/xen/arch/powerpc/xen.lds.SMon Jan 22 15:52:46 2007 -0500
@@ -7,62 +7,113 @@ OUTPUT_FORMAT("elf64-powerpc", "elf64-po
"elf64-powerpc")
OUTPUT_ARCH(powerpc:common64)
ENTRY(_start)
+SEARCH_DIR("=/usr/local/lib64"); SEARCH_DIR("=/lib64");
SEARCH_DIR("=/usr/lib64"); SEARCH_DIR("=/usr/local/lib"); SEARCH_DIR("=/lib");
SEARCH_DIR("=/usr/lib");
+/* Do we need any of these for elf?
+ __DYNAMIC = 0;*/
PHDRS
{
text PT_LOAD;
}
SECTIONS
{
- /* This is the address that we are linking at */
. = 0x0040;
PROVIDE(_text = .);
PROVIDE(_stext = .);
/* Read-only sections, merged into text segment: */
+ .interp : { *(.interp) } :text
+ .hash : { *(.hash) }
+ .dynsym : { *(.dynsym) }
+ .dynstr : { *(.dynstr) }
+ .gnu.version: { *(.gnu.version) }
+ .gnu.version_d : { *(.gnu.version_d) }
+ .gnu.version_r : { *(.gnu.version_r) }
+ .rel.dyn:
+{
+ *(.rel.init)
+ *(.rel.text .rel.text.* .rel.gnu.linkonce.t.*)
+ *(.rel.fini)
+ *(.rel.rodata .rel.rodata.* .rel.gnu.linkonce.r.*)
+ *(.rel.data .rel.data.* .rel.gnu.linkonce.d.*)
+ *(.rel.tdata .rel.tdata.* .rel.gnu.linkonce.td.*)
+ *(.rel.tbss .rel.tbss.* .rel.gnu.linkonce.tb.*)
+ *(.rel.ctors)
+ *(.rel.dtors)
+ *(.rel.got)
+ *(.rel.sdata .rel.sdata.* .rel.gnu.linkonce.s.*)
+ *(.rel.sbss .rel.sbss.* .rel.gnu.linkonce.sb.*)
+ *(.rel.sdata2 .rel.sdata2.* .rel.gnu.linkonce.s2.*)
+ *(.rel.sbss2 .rel.sbss2.* .rel.gnu.linkonce.sb2.*)
+ *(.rel.bss .rel.bss.* .rel.gnu.linkonce.b.*)
+}
+ .rela.dyn :
+{
+ *(.rela.init)
+ *(.rela.text .rela.text.* .rela.gnu.linkonce.t.*)
+ *(.rela.fini)
+ *(.rela.rodata .rela.rodata.* .rela.gnu.linkonce.r.*)
+ *(.rela.data .rela.data.* .rela.gnu.linkonce.d.*)
+ *(.rela.tdata .rela.tdata.* .rela.gnu.linkonce.td.*)
+ *(.rela.tbss .rela.tbss.* .rela.gnu.linkonce.tb.*)
+ *(.rela.ctors)
+ *(.rela.dtors)
+ *(.rela.got)
+ *(.rela.toc)
+ *(.rela.sdata .rela.sdata.* .rela.gnu.linkonce.s.*)
+ *(.rela.sbss .rela.sbss.* .rela.gnu.linkonce.sb.*)
+ *(.rela.sdata2 .rela.sdata2.* .rela.gnu.linkonce.s2.*)
+ *(.rela.sbss2 .rela.sbss2.* .rela.gnu.linkonce.sb2.*)
+ *(.rela.bss .rela.bss.* .rela.gnu.linkonce.b.*)
+}
+ .rel.plt: { *(.rel.plt) }
+ .rela.plt : { *(.rela.plt) }
+ .rela.tocbss : { *(.rela.tocbss) }
+ .init :
+ {
+KEEP (*(.init))
+ } =0x6000
.text :
{
-*(.text)
+*(.text .stub .text.* .gnu.linkonce.t.*)
/* .gnu.warning sections are handled specially by elf32.em. */
*(.gnu.warning)
- } : text
- /* end of text */
+*(.sfpr .glink)
+ } =0x6000
+ .fini :
+ {
+KEEP (*(.fini))
+ } =0x6000
PROVIDE (__etext = .);
PROVIDE (_etext = .);
PROVIDE (etext = .);
-
- /* read only data */
- .rodata : { *(.rodata .rodata.*) } : text
- .rodata1: { *(.rodata1) } : text
- .sdata2 : { *(.sdata2 .sdata2.*) } : text
- .sbss2 : { *(.sbss2 .sbss2.*) } : text
-
- . = ALIGN(64);
- __start___ex_table = .;
- __ex_table : { *(__ex_table) } : text
- __stop___ex_table = .;
- . = ALIGN(64);
-
+ .rodata : { *(.rodata .rodata.* .gnu.linkonce.r.*) }
+ .rodata1: { *(.rodata1) }
+ .sdata2 : { *(.sdata2 .sdata2.* .gnu.linkonce.s2.*) }
+ .sbss2 : { *(.sbss2 .sbss2.* .gnu.linkonce.sb2.*) }
+ .eh_frame_hdr : { *(.eh_frame_hdr) }
+ /* Adjust the address for the data segment. We want to adjust up to
+ the same address within the page on the next page up. */
+ . = ALIGN (0x1) - ((0x1 - .) & (0x1 - 1)); . =
DATA_SEGMENT_ALIGN (0x1, 0x1000);
+ /* Ensure the __preinit_array_start label is properly aligned. We
+ could instead move the label definition inside the section, but
+ the linker would then create the section even if it turns out to
+ be empty, which isn't pretty. */
+ . = ALIGN(64 / 8);
+ PROVIDE (__preinit_array_start = .);
+ .preinit_array : { *(.preinit_array) }
+ PROVIDE (__preinit_array_end = .);
+ PROVIDE (__init_array_start = .);
+ .init_array : { *(.init_array) }
+ PROVIDE (__init_array_end = .);
+
