| Message ID | 1401913653-23804-1-git-send-email-abrodkin@synopsys.com |
|---|---|
| State | Accepted |
| Commit | cde947f5f5548e47ef66c91ac9f7756f85a95bb1 |
| Headers | show |
Hi all, On Thu, 2014-06-05 at 00:27 +0400, Alexey Brodkin wrote: > Currently we configure uClibc to use kernel headers from "staging" folder with > KERNEL_HEADERS="$(STAGING_DIR)/usr/include". This path is added to include > search path of uClibc build system in Rules.mak "CFLAGS += -I$(KERNEL_HEADERS)". > > At the same time on uClibc installation to "staging" we point to the same > location "$(STAGING_DIR)/usr" (headers effectively go in "usr/include"). > > So after every installation to "staging" dependences get touched (even though we > copy the same headers every time) and so we may see lots of sources in uClibc > get rebuilt. > > This has 2 consequences: > 1. Longer build time - becase even on ordinary buildroot build uClibc is built > twice. On "uclibc building" and on "uclibc installation to target". > > 2. Symbols in libuClibc built initially (that is later installed in > "staging/sysroot") are situated with different offset compared to second build > (later copied in "target"). This happens because as described above only part > of sources get rebuilt and then on final linkage object files are linked in > different order. > > And (2) leads to problems on remote rebugging: gdbserver reports offsets that > correspond to pointless assembly in libuClibc on host. > > Here's how it looks like. > > Before this patch: > $ cd ~/br2_output/i586/target/lib > $ i586-buildroot-linux-uclibc-readelf -s libuClibc-0.9.33.2.so | grep kill > 423: 0000c42c 54 FUNC GLOBAL DEFAULT 7 kill > > $ cd ~/br2_output/i586/staging/lib > $ i586-buildroot-linux-uclibc-readelf -s libuClibc-0.9.33.2.so | grep kill > 423: 0000b518 54 FUNC GLOBAL DEFAULT 7 kill > > After this patch: > $ cd ~/br2_output/i586/target/lib > $ i586-buildroot-linux-uclibc-readelf -s libuClibc-0.9.33.2.so | grep kill > 423: 0000b518 54 FUNC GLOBAL DEFAULT 7 kill > > $ cd ~/br2_output/i586/staging/lib > $ i586-buildroot-linux-uclibc-readelf -s libuClibc-0.9.33.2.so | grep kill > 423: 0000b518 54 FUNC GLOBAL DEFAULT 7 kill Any thoughts on this one? Regards, Alexey
>>>>> "Alexey" == Alexey Brodkin <Alexey.Brodkin@synopsys.com> writes: Hi, > Any thoughts on this one? Sorry, I haven't had time to review it yet. It certainly sounds good. I will get back to you later today or tomorrow.
Dear Peter, On Tue, 2014-06-10 at 21:21 +0200, Peter Korsgaard wrote: > >>>>> "Alexey" == Alexey Brodkin <Alexey.Brodkin@synopsys.com> writes: > > Hi, > > > Any thoughts on this one? > > Sorry, I haven't had time to review it yet. It certainly sounds good. I > will get back to you later today or tomorrow. > Please pardon me for this reminder but I'm wondering if you were able to try this patch? Regards, Alexey
>>>>> "Alexey" == Alexey Brodkin <Alexey.Brodkin@synopsys.com> writes: > Dear Peter, >> > Any thoughts on this one? >> >> Sorry, I haven't had time to review it yet. It certainly sounds good. I >> will get back to you later today or tomorrow. >> > Please pardon me for this reminder but I'm wondering if you were able to > try this patch? I'm really sorry, but real life got in the way. I'll test it now.
Dear Peter, On Mon, 2014-06-16 at 09:20 +0200, Peter Korsgaard wrote: > >>>>> "Alexey" == Alexey Brodkin <Alexey.Brodkin@synopsys.com> writes: > > > Dear Peter, > > >> > Any thoughts on this one? > >> > >> Sorry, I haven't had time to review it yet. It certainly sounds good. I > >> will get back to you later today or tomorrow. > >> > > > Please pardon me for this reminder but I'm wondering if you were able to > > try this patch? > > I'm really sorry, but real life got in the way. I'll test it now. I'm wondering if you faced any issues during your testing, may I help you somehow? Regards, Alexey
>>>>> "Alexey" == Alexey Brodkin <Alexey.Brodkin@synopsys.com> writes: Hi, >> > Please pardon me for this reminder but I'm wondering if you were able to >> > try this patch? >> >> I'm really sorry, but real life got in the way. I'll test it now. > I'm wondering if you faced any issues during your testing, may I help > you somehow? Sorry, I didn't got around to check it before now. Looks good, and I have verified that it isn't needed for glibc and musl. Committed, thanks.
diff --git a/package/linux-headers/linux-headers.mk b/package/linux-headers/linux-headers.mk index 7b3edf4..8302d56 100644 --- a/package/linux-headers/linux-headers.mk +++ b/package/linux-headers/linux-headers.mk @@ -26,6 +26,20 @@ LINUX_HEADERS_ADD_TOOLCHAIN_DEPENDENCY = NO # This results in seemingly errors like: # [...]/scripts/gcc-version.sh: line 26: arc-linux-uclibc-gcc: command not found # Those can be safely ignored. + +# This step is required to have a separate linux headers location for +# uClibc building. This way uClibc doesn't modify linux headers on installation +# of "its" headers +define LINUX_HEADERS_CONFIGURE_CMDS + (cd $(@D); \ + $(TARGET_MAKE_ENV) $(MAKE) \ + ARCH=$(KERNEL_ARCH) \ + HOSTCC="$(HOSTCC)" \ + HOSTCFLAGS="$(HOSTCFLAGS)" \ + HOSTCXX="$(HOSTCXX)" \ + headers_install) +endef + define LINUX_HEADERS_INSTALL_STAGING_CMDS (cd $(@D); \ $(TARGET_MAKE_ENV) $(MAKE) \ diff --git a/package/uclibc/uclibc.mk b/package/uclibc/uclibc.mk index 717cf53..144f993 100644 --- a/package/uclibc/uclibc.mk +++ b/package/uclibc/uclibc.mk @@ -418,7 +418,7 @@ define UCLIBC_SETUP_DOT_CONFIG $(call UCLIBC_OPT_SET,CROSS_COMPILER_PREFIX,"$(TARGET_CROSS)",$(@D)) $(call UCLIBC_OPT_SET,TARGET_$(UCLIBC_TARGET_ARCH),y,$(@D)) $(call UCLIBC_OPT_SET,TARGET_ARCH,"$(UCLIBC_TARGET_ARCH)",$(@D)) - $(call UCLIBC_OPT_SET,KERNEL_HEADERS,"$(STAGING_DIR)/usr/include",$(@D)) + $(call UCLIBC_OPT_SET,KERNEL_HEADERS,"$(LINUX_HEADERS_DIR)/usr/include",$(@D)) $(call UCLIBC_OPT_SET,RUNTIME_PREFIX,"/",$(@D)) $(call UCLIBC_OPT_SET,DEVEL_PREFIX,"/usr",$(@D)) $(call UCLIBC_OPT_SET,SHARED_LIB_LOADER_PREFIX,"/lib",$(@D))
Currently we configure uClibc to use kernel headers from "staging" folder with KERNEL_HEADERS="$(STAGING_DIR)/usr/include". This path is added to include search path of uClibc build system in Rules.mak "CFLAGS += -I$(KERNEL_HEADERS)". At the same time on uClibc installation to "staging" we point to the same location "$(STAGING_DIR)/usr" (headers effectively go in "usr/include"). So after every installation to "staging" dependences get touched (even though we copy the same headers every time) and so we may see lots of sources in uClibc get rebuilt. This has 2 consequences: 1. Longer build time - becase even on ordinary buildroot build uClibc is built twice. On "uclibc building" and on "uclibc installation to target". 2. Symbols in libuClibc built initially (that is later installed in "staging/sysroot") are situated with different offset compared to second build (later copied in "target"). This happens because as described above only part of sources get rebuilt and then on final linkage object files are linked in different order. And (2) leads to problems on remote rebugging: gdbserver reports offsets that correspond to pointless assembly in libuClibc on host. Here's how it looks like. Before this patch: $ cd ~/br2_output/i586/target/lib $ i586-buildroot-linux-uclibc-readelf -s libuClibc-0.9.33.2.so | grep kill 423: 0000c42c 54 FUNC GLOBAL DEFAULT 7 kill $ cd ~/br2_output/i586/staging/lib $ i586-buildroot-linux-uclibc-readelf -s libuClibc-0.9.33.2.so | grep kill 423: 0000b518 54 FUNC GLOBAL DEFAULT 7 kill After this patch: $ cd ~/br2_output/i586/target/lib $ i586-buildroot-linux-uclibc-readelf -s libuClibc-0.9.33.2.so | grep kill 423: 0000b518 54 FUNC GLOBAL DEFAULT 7 kill $ cd ~/br2_output/i586/staging/lib $ i586-buildroot-linux-uclibc-readelf -s libuClibc-0.9.33.2.so | grep kill 423: 0000b518 54 FUNC GLOBAL DEFAULT 7 kill Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Peter Korsgaard <peter@korsgaard.com> Cc: Noam Camus <noamc@ezchip.com> --- package/linux-headers/linux-headers.mk | 14 ++++++++++++++ package/uclibc/uclibc.mk | 2 +- 2 files changed, 15 insertions(+), 1 deletion(-)