Re: MI linker script
I've found that linker script can have multiple SECTIONS commands. This may be able to save the intermediate ld -r by concatenate MI + MD scripts. Let me try...
Re: MI linker script
On Nov 9, 11:52am, Masao Uebayashi wrote: } On Sun, Nov 9, 2014 at 11:22 AM, John Nemeth jnem...@cue.bc.ca wrote: } The question wasn't simply about ld -r stuff. It was about } the entire program of config(1) changes, linking changes, module(9) } changes, etc. There's an awful lot of stuff happening to major } parts of the system without any discussion. } } The entire program of config(1) is a bit too exaggerated. I'm } rather hunting low-hanging fruits. By program I didn't mean config(1), I meant what you're doing. And, what you are doing appears to be a lot more then just hunting low-hanging fruits. }-- End of excerpt from Masao Uebayashi
Re: MI linker script
In article 20141108052307.gb20...@gw.tombi.co.jp, Masao Uebayashi uebay...@gmail.com wrote: For reference, this *actually* works, and intermediate *.ro is rm'ed. (This needs the uncommitted __SYMVAL() change in sys/cdefs_elf.h.) I'm not committing this soon, to give people time to overcome fear against ld -r. I still don't understand what this buys us. It seems to add complexity (depending on ld -r to work properly and an additional step), it is slower, and requires more disk space. christos
Re: MI linker script
On Sat, Nov 8, 2014 at 11:53 PM, Christos Zoulas chris...@astron.com wrote: depending on ld -r to work properly I know none of you trust me, but you don't trust ld -r? It is not me but others (mainly dsl@) who repeatedly brought up usefulness of ld -r. I didn't know how to use it, whether it can handle ldscript. After one week, I can't believe life without it. ld -r is your friend. :)))
Re: MI linker script
In article cadbf7ecoaqbeuqjq5hq2ubpnkp4yftfre_tmakvtrdh_0hp...@mail.gmail.com, Masao Uebayashi uebay...@gmail.com wrote: On Sat, Nov 8, 2014 at 11:53 PM, Christos Zoulas chris...@astron.com wrote: depending on ld -r to work properly I know none of you trust me, but you don't trust ld -r? It is not me but others (mainly dsl@) who repeatedly brought up usefulness of ld -r. I didn't know how to use it, whether it can handle ldscript. After one week, I can't believe life without it. ld -r is your friend. :))) I am not sold :-) Why should I add more steps to linking? What does it buy me? I can understand using -r when building shared libraries, kernel modules and other things that don't need final linking, but the kernel itself eventually needs to be linked completely so why do it in steps? If nothing else, it will be at least twice as slow. christos
Re: MI linker script
On Nov 9, 1:25am, Masao Uebayashi wrote: } On Sat, Nov 8, 2014 at 11:53 PM, Christos Zoulas chris...@astron.com wrote: } depending on ld -r to work properly } } I know none of you trust me, but you don't trust ld -r? It has nothing to do with trust. It's more like wanting to know what the heck is going on. Normally major work like this would start with a discussion or at least an announcement of the plan. Instead all that happened is suddenly we see a major overhaul of a critical item with no clue as to why. So, what is the plan? Why are you doing this? What are your goals (i.e. what is the expected end result)? What are you doing with modules? }-- End of excerpt from Masao Uebayashi
Re: MI linker script
Something like this: https://mail-index.netbsd.org/tech-kern/2012/05/28/msg013235.html In short: making kernel build better by sharing *.o On Sun, Nov 9, 2014 at 5:07 AM, John Nemeth jnem...@cue.bc.ca wrote: On Nov 9, 1:25am, Masao Uebayashi wrote: } On Sat, Nov 8, 2014 at 11:53 PM, Christos Zoulas chris...@astron.com wrote: } depending on ld -r to work properly } } I know none of you trust me, but you don't trust ld -r? It has nothing to do with trust. It's more like wanting to know what the heck is going on. Normally major work like this would start with a discussion or at least an announcement of the plan. Instead all that happened is suddenly we see a major overhaul of a critical item with no clue as to why. So, what is the plan? Why are you doing this? What are your goals (i.e. what is the expected end result)? What are you doing with modules? }-- End of excerpt from Masao Uebayashi
Re: MI linker script
On Sun, Nov 9, 2014 at 1:43 AM, Christos Zoulas chris...@astron.com wrote: In article cadbf7ecoaqbeuqjq5hq2ubpnkp4yftfre_tmakvtrdh_0hp...@mail.gmail.com, Masao Uebayashi uebay...@gmail.com wrote: On Sat, Nov 8, 2014 at 11:53 PM, Christos Zoulas chris...@astron.com wrote: depending on ld -r to work properly I know none of you trust me, but you don't trust ld -r? It is not me but others (mainly dsl@) who repeatedly brought up usefulness of ld -r. I didn't know how to use it, whether it can handle ldscript. After one week, I can't believe life without it. ld -r is your friend. :))) I am not sold :-) Why should I add more steps to linking? What does it buy me? That way I can have more control by indirection. I can understand using -r when building shared libraries, kernel modules and other things that don't need final linking, but the kernel itself eventually needs to be linked completely so why do it in steps? If nothing else, it will be at least twice as slow. One idea is to make a linker script compiler, to generate one by mixing MI + MD ones. Speaking of slowness and/or space, how many kernels do you build for evbarm, what part of objects are same and/or different? Will you do that waste of energy forever?
Re: MI linker script
On Nov 9, 10:35am, Masao Uebayashi wrote: } On Sun, Nov 9, 2014 at 5:07 AM, John Nemeth jnem...@cue.bc.ca wrote: } On Nov 9, 1:25am, Masao Uebayashi wrote: } } On Sat, Nov 8, 2014 at 11:53 PM, Christos Zoulas chris...@astron.com wrote: } } depending on ld -r to work properly } } } } I know none of you trust me, but you don't trust ld -r? } } It has nothing to do with trust. It's more like wanting to } know what the heck is going on. Normally major work like this } would start with a discussion or at least an announcement of the } plan. Instead all that happened is suddenly we see a major overhaul } of a critical item with no clue as to why. } } So, what is the plan? Why are you doing this? What are your } goals (i.e. what is the expected end result)? What are you doing } with modules? } } Something like this: } https://mail-index.netbsd.org/tech-kern/2012/05/28/msg013235.html } } In short: making kernel build better by sharing *.o The question wasn't simply about ld -r stuff. It was about the entire program of config(1) changes, linking changes, module(9) changes, etc. There's an awful lot of stuff happening to major parts of the system without any discussion. }-- End of excerpt from Masao Uebayashi
Re: MI linker script
On Sun, Nov 9, 2014 at 11:22 AM, John Nemeth jnem...@cue.bc.ca wrote: The question wasn't simply about ld -r stuff. It was about the entire program of config(1) changes, linking changes, module(9) changes, etc. There's an awful lot of stuff happening to major parts of the system without any discussion. The entire program of config(1) is a bit too exaggerated. I'm rather hunting low-hanging fruits.
Re: MI linker script
Maybe I should rm the temporary *.ro immediately.
Re: MI linker script
On Sat, Nov 8, 2014 at 1:47 AM, Matt Thomas m...@3am-software.com wrote: linker scripts aren't used when doing -r. Not used implicitly. You can explicitly specify one. (I didn't know this fact one week ago. I understand your feeling.)
Re: MI linker script
On Nov 7, 2014, at 9:10 AM, Masao Uebayashi uebay...@gmail.com wrote: On Sat, Nov 8, 2014 at 1:47 AM, Matt Thomas m...@3am-software.com wrote: linker scripts aren't used when doing -r. Not used implicitly. You can explicitly specify one. (I didn't know this fact one week ago. I understand your feeling.) Again, why? the final linker script is the important one. Using one with doesn't really do anything significant.
Re: MI linker script
On Sat, Nov 8, 2014 at 2:30 AM, Matt Thomas m...@3am-software.com wrote: On Nov 7, 2014, at 9:10 AM, Masao Uebayashi uebay...@gmail.com wrote: On Sat, Nov 8, 2014 at 1:47 AM, Matt Thomas m...@3am-software.com wrote: linker scripts aren't used when doing -r. Not used implicitly. You can explicitly specify one. (I didn't know this fact one week ago. I understand your feeling.) Again, why? the final linker script is the important one. Using one with doesn't really do anything significant. MD linkage is important for MD loaders. MI linkage (e.g. .data alignment) is important for all kernels. They can be done at different phases.
Re: MI linker script
For reference, this *actually* works, and intermediate *.ro is rm'ed. (This
needs the uncommitted __SYMVAL() change in sys/cdefs_elf.h.)
I'm not committing this soon, to give people time to overcome fear against
ld -r.
Index: sys/conf/Makefile.kern.inc
===
RCS file: /cvsroot/src/sys/conf/Makefile.kern.inc,v
retrieving revision 1.178
diff -p -u -r1.178 Makefile.kern.inc
--- sys/conf/Makefile.kern.inc 6 Nov 2014 12:02:59 - 1.178
+++ sys/conf/Makefile.kern.inc 8 Nov 2014 04:32:56 -
@@ -223,8 +223,9 @@ ${_cfile:T:R}.o: ${_cfile}
# load lines for config xxx will be emitted as:
# xxx: ${SYSTEM_DEP} swap.o vers.o build_kernel
+MI_LDSCRIPT= $S/conf/kern.ldscript
SYSTEM_OBJ?= ${MD_OBJS} ${MI_OBJS} ${OBJS:O} ${SYSLIBCOMPAT} ${LIBKERN}
-SYSTEM_DEP+= Makefile ${SYSTEM_OBJ:O} .gdbinit
+SYSTEM_DEP+= Makefile ${SYSTEM_OBJ:O} .gdbinit ${MI_LDSCRIPT}
.if defined(KERNLDSCRIPT)
SYSTEM_DEP+= ${KERNLDSCRIPT}
.endif
@@ -234,10 +235,16 @@ SYSTEM_CTFMERGE= ${CTFMERGE} ${CTFMFLAGS
SYSTEM_CTFMERGE= ${_MKSHECHO}
.endif
SYSTEM_LD_HEAD?=@rm -f $@
+SYSTEM_LD_RO?= @${_MKSHMSG}link ${.CURDIR:T}/${.TARGET}.ro; \
+ ${_MKSHECHO}\
+ ${LD} -r -T ${MI_LDSCRIPT} -Map $@.ro.map -o $@.ro\
+ '$${SYSTEM_OBJ}' '$${EXTRA_OBJ}' vers.o; \
+ ${LD} -r -T ${MI_LDSCRIPT} -Map $@.ro.map -o $@.ro\
+ ${SYSTEM_OBJ} ${EXTRA_OBJ} vers.o
SYSTEM_LD?=@${_MKSHMSG}link ${.CURDIR:T}/${.TARGET}; \
${_MKSHECHO}\
- ${LD} -Map $@.map --cref ${LINKFLAGS} -o $@ '$${SYSTEM_OBJ}'
'$${EXTRA_OBJ}' vers.o; \
- ${LD} -Map $@.map --cref ${LINKFLAGS} -o $@ ${SYSTEM_OBJ}
${EXTRA_OBJ} vers.o
+ ${LD} -Map $@.map --cref ${LINKFLAGS} -o $@ $@.ro; \
+ ${LD} -Map $@.map --cref ${LINKFLAGS} -o $@ $@.ro
TEXTADDR?= ${LOADADDRESS} # backwards compatibility
LINKTEXT?= ${TEXTADDR:C/.+/-Ttext /}
@@ -346,7 +353,7 @@ assym.h machdep.o: Makefile
.if !target(__CLEANKERNEL)
__CLEANKERNEL: .USE
${_MKMSG} ${.TARGET}ing the kernel objects
- rm -f ${KERNELS} *.map eddep tags *.[io] *.ko *.ln [a-z]*.s vers.c \
+ rm -f ${KERNELS} *.map eddep tags *.[io] *.ro *.ko *.ln [a-z]*.s vers.c
\
[Ee]rrs linterrs makelinks assym.h.tmp assym.h \
${EXTRA_KERNELS} ${EXTRA_CLEAN}
.endif
@@ -553,21 +560,26 @@ CPPFLAGS.kern_ksyms_buf.c+= -DCOPY_SYMTA
.if !defined(COPY_SYMTAB)
build_kernel: .USE
${SYSTEM_LD_HEAD}
- ${SYSTEM_LD} swap${.TARGET}.o
+ ${SYSTEM_LD_RO} swap${.TARGET}.o
+ ${SYSTEM_LD}
${SYSTEM_LD_TAIL_STAGE2}
+ @rm -f ${.TARGET}.ro
.else
build_kernel: .USE
${CC} ${CFLAGS} ${CPPFLAGS} -DCOPY_SYMTAB \
-c $S/kern/kern_ksyms_buf.c -o kern_ksyms_buf.o
${SYSTEM_LD_HEAD}
- ${SYSTEM_LD} swap${.TARGET}.o kern_ksyms_buf.o
+ ${SYSTEM_LD_RO} swap${.TARGET}.o kern_ksyms_buf.o
+ ${SYSTEM_LD}
${SYSTEM_LD_TAIL_STAGE1}
${CC} ${CFLAGS} ${CPPFLAGS} -DCOPY_SYMTAB \
-DSYMTAB_SPACE=$$(${DBSYM} -P ${.TARGET}${TARGETSFX}) \
-c $S/kern/kern_ksyms_buf.c -o kern_ksyms_buf_real.o
${SYSTEM_LD_HEAD}
- ${SYSTEM_LD} swap${.TARGET}.o kern_ksyms_buf_real.o
+ ${SYSTEM_LD_RO} swap${.TARGET}.o kern_ksyms_buf_real.o
+ ${SYSTEM_LD}
${SYSTEM_LD_TAIL_STAGE2}
+ @rm -f ${.TARGET}.ro
.endif
.include bsd.files.mk
Index: sys/conf/kern.ldscript
===
RCS file: sys/conf/kern.ldscript
diff -N sys/conf/kern.ldscript
--- /dev/null 1 Jan 1970 00:00:00 -
+++ sys/conf/kern.ldscript 8 Nov 2014 04:32:56 -
@@ -0,0 +1,20 @@
+/* $NetBSD$*/
+
+SECTIONS
+{
+ .data :
+ {
+*(.data)
+ }
+ . = ALIGN(COHERENCY_UNIT);
+ .data.cacheline_aligned :
+ {
+*(.data.cacheline_aligned)
+ }
+ . = ALIGN(COHERENCY_UNIT);
+ .data.read_mostly :
+ {
+*(.data.read_mostly)
+ }
+ . = ALIGN(COHERENCY_UNIT);
+}
Index: sys/conf/param.c
===
RCS file: /cvsroot/src/sys/conf/param.c,v
retrieving revision 1.64
diff -p -u -r1.64 param.c
--- sys/conf/param.c9 Jun 2012 02:31:14 - 1.64
+++ sys/conf/param.c8 Nov 2014 04:32:57 -
@@ -219,3 +219,8 @@ const int mclbytes = MCLBYTES;
* Values in support of POSIX semaphores.
*/
intksem_max = KSEM_MAX;
+
+/*
+ * Symbols for linker script.
+ */
+__SYMVAL(COHERENCY_UNIT, COHERENCY_UNIT);
