* [Buildroot] [PATCH v2 1/4] toolchain: wrap 'ld' with toolchain-wrapper
@ 2016-04-05 19:45 Jan Heylen
2016-04-05 19:45 ` [Buildroot] [PATCH v2 2/4] toolchain: add option to specify ld emulation Jan Heylen
` (3 more replies)
0 siblings, 4 replies; 14+ messages in thread
From: Jan Heylen @ 2016-04-05 19:45 UTC (permalink / raw)
To: buildroot
extend the toolchain wrapper to also wrap the ld linker.
Tested with gnu ld and gnu 'gold'
BR2_BINUTILS_EXTRA_CONFIG_OPTIONS="--enable-gold=default --enable-plugins"
make host-binutils result in: (ld and ld.gold are equal)
<ARCH>-buildroot-linux-uclibc-ld -> toolchain-wrapper
<ARCH>-buildroot-linux-uclibc-ld.bfd
<ARCH>-buildroot-linux-uclibc-ld.br_real
<ARCH>-buildroot-linux-uclibc-ld.gold -> toolchain-wrapper
<ARCH>-buildroot-linux-uclibc-ld.gold.br_real
<ARCH>-linux-ld -> toolchain-wrapper
<ARCH>-linux-ld.br_real -> <ARCH>-buildroot-linux-uclibc-ld.br_real
<ARCH>-linux-ld.gold -> toolchain-wrapper
<ARCH>-linux-ld.gold.br_real -> <ARCH>-buildroot-linux-uclibc-ld.gold.br_real
toolchain-wrapper
after host-gcc-initial, toolchain-wrapper will be rebuild, but the ld
symlinks remain
Based upon patch from Thomas Petazzoni:
http://thread.gmane.org/gmane.comp.lib.uclibc.buildroot/60942
---
package/binutils/binutils.mk | 23 ++++++
package/gcc/gcc-initial/gcc-initial.mk | 1 +
toolchain/toolchain-external/toolchain-external.mk | 2 +-
toolchain/toolchain-wrapper.c | 94 ++++++++++++++--------
4 files changed, 85 insertions(+), 35 deletions(-)
diff --git a/package/binutils/binutils.mk b/package/binutils/binutils.mk
index ca39f0b..2743175 100644
--- a/package/binutils/binutils.mk
+++ b/package/binutils/binutils.mk
@@ -82,6 +82,29 @@ HOST_BINUTILS_CONF_OPTS = \
$(BINUTILS_DISABLE_GDB_CONF_OPTS) \
$(BINUTILS_EXTRA_CONFIG_OPTIONS)
+#TODO generalise this, this is in 3 places now...
+HOST_BINUTILS_TOOLCHAIN_WRAPPER_ARGS += -DBR_CROSS_PATH_SUFFIX='".br_real"'
+HOST_BINUTILS_POST_BUILD_HOOKS += TOOLCHAIN_BUILD_WRAPPER
+HOST_BINUTILS_POST_INSTALL_HOOKS += HOST_BINUTILS_INSTALL_WRAPPER_AND_SIMPLE_SYMLINKS
+
+# Avoid that a .br_real is symlinked a second time.
+define HOST_BINUTILS_INSTALL_WRAPPER_AND_SIMPLE_SYMLINKS
+ $(Q)cd $(HOST_DIR)/usr/bin; \
+ for i in $(GNU_TARGET_NAME)-*; do \
+ case "$$i" in \
+ *.br_real) \
+ ;; \
+ *ld) \
+ rm -f $$i.br_real; \
+ mv $$i $$i.br_real; \
+ ln -sf toolchain-wrapper $$i; \
+ ln -sf toolchain-wrapper $(ARCH)-linux$${i##$(GNU_TARGET_NAME)}; \
+ ln -snf $$i.br_real $(ARCH)-linux$${i##$(GNU_TARGET_NAME)}.br_real; \
+ ;; \
+ esac; \
+ done
+endef
+
# binutils run configure script of subdirs at make time, so ensure
# our TARGET_CONFIGURE_ARGS are taken into consideration for those
define BINUTILS_BUILD_CMDS
diff --git a/package/gcc/gcc-initial/gcc-initial.mk b/package/gcc/gcc-initial/gcc-initial.mk
index 1e58d8b..62a2ef6 100644
--- a/package/gcc/gcc-initial/gcc-initial.mk
+++ b/package/gcc/gcc-initial/gcc-initial.mk
@@ -60,6 +60,7 @@ HOST_GCC_INITIAL_MAKE_OPTS += all-target-libgcc
HOST_GCC_INITIAL_INSTALL_OPTS += install-target-libgcc
endif
+#rebuild the toolchain-wrapper (e.g. for ccache) already build once in binutils
HOST_GCC_INITIAL_TOOLCHAIN_WRAPPER_ARGS += $(HOST_GCC_COMMON_TOOLCHAIN_WRAPPER_ARGS)
HOST_GCC_INITIAL_POST_BUILD_HOOKS += TOOLCHAIN_BUILD_WRAPPER
HOST_GCC_INITIAL_POST_INSTALL_HOOKS += HOST_GCC_INSTALL_WRAPPER_AND_SIMPLE_SYMLINKS
diff --git a/toolchain/toolchain-external/toolchain-external.mk b/toolchain/toolchain-external/toolchain-external.mk
index ff4ae5e..7994808 100644
--- a/toolchain/toolchain-external/toolchain-external.mk
+++ b/toolchain/toolchain-external/toolchain-external.mk
@@ -741,7 +741,7 @@ define TOOLCHAIN_EXTERNAL_INSTALL_WRAPPER
*-ar|*-ranlib|*-nm) \
ln -sf $$(echo $$i | sed 's%^$(HOST_DIR)%../..%') .; \
;; \
- *cc|*cc-*|*++|*++-*|*cpp) \
+ *cc|*cc-*|*++|*++-*|*cpp|*ld) \
ln -sf toolchain-wrapper $$base; \
;; \
*gdb|*gdbtui) \
diff --git a/toolchain/toolchain-wrapper.c b/toolchain/toolchain-wrapper.c
index 887058f..ec069da 100644
--- a/toolchain/toolchain-wrapper.c
+++ b/toolchain/toolchain-wrapper.c
@@ -42,7 +42,7 @@ static char sysroot[PATH_MAX];
*/
#define EXCLUSIVE_ARGS 3
-static char *predef_args[] = {
+static char *gcc_predef_args[] = {
#ifdef BR_CCACHE
ccache_path,
#endif
@@ -80,6 +80,19 @@ static char *predef_args[] = {
#endif
};
+static char *ld_predef_args[] = {
+ path,
+#ifdef BR_BINFMT_FLAT
+ "-elf2flt",
+#endif
+#ifdef BR_MIPS_TARGET_LITTLE_ENDIAN
+ "-EL",
+#endif
+#if defined(BR_MIPS_TARGET_BIG_ENDIAN) || defined(BR_ARC_TARGET_BIG_ENDIAN)
+ "-EB",
+#endif
+};
+
static void check_unsafe_path(const char *path, int paranoid)
{
char **c;
@@ -109,6 +122,8 @@ int main(int argc, char **argv)
char *paranoid_wrapper;
int paranoid;
int ret, i, count = 0, debug;
+ int predef_args_sz;
+ int ld_wrapper;
/* Calculate the relative paths */
basename = strrchr(progpath, '/');
@@ -169,7 +184,13 @@ int main(int argc, char **argv)
return 3;
}
- cur = args = malloc(sizeof(predef_args) +
+ ld_wrapper = (strncmp("ld", basename + strlen(basename) - 2, 2) == 0) ? 1 : 0;
+ if (ld_wrapper)
+ predef_args_sz = sizeof(ld_predef_args);
+ else
+ predef_args_sz = sizeof(gcc_predef_args);
+
+ cur = args = malloc(predef_args_sz +
(sizeof(char *) * (argc + EXCLUSIVE_ARGS)));
if (args == NULL) {
perror(__FILE__ ": malloc");
@@ -177,42 +198,45 @@ int main(int argc, char **argv)
}
/* start with predefined args */
- memcpy(cur, predef_args, sizeof(predef_args));
- cur += sizeof(predef_args) / sizeof(predef_args[0]);
+ memcpy(cur, ld_wrapper ? ld_predef_args : gcc_predef_args, predef_args_sz);
+ cur += predef_args_sz / sizeof(char *);
+ /* following extras should only happen for non-ld wrappers */
+ if (!ld_wrapper) {
#ifdef BR_FLOAT_ABI
- /* add float abi if not overridden in args */
- for (i = 1; i < argc; i++) {
- if (!strncmp(argv[i], "-mfloat-abi=", strlen("-mfloat-abi=")) ||
- !strcmp(argv[i], "-msoft-float") ||
- !strcmp(argv[i], "-mhard-float"))
- break;
- }
+ /* add float abi if not overridden in args */
+ for (i = 1; i < argc; i++) {
+ if (!strncmp(argv[i], "-mfloat-abi=", strlen("-mfloat-abi=")) ||
+ !strcmp(argv[i], "-msoft-float") ||
+ !strcmp(argv[i], "-mhard-float"))
+ break;
+ }
- if (i == argc)
- *cur++ = "-mfloat-abi=" BR_FLOAT_ABI;
+ if (i == argc)
+ *cur++ = "-mfloat-abi=" BR_FLOAT_ABI;
#endif
#if defined(BR_ARCH) || \
- defined(BR_CPU)
- /* Add our -march/cpu flags, but only if none of
- * -march/mtune/mcpu are already specified on the commandline
- */
- for (i = 1; i < argc; i++) {
- if (!strncmp(argv[i], "-march=", strlen("-march=")) ||
- !strncmp(argv[i], "-mtune=", strlen("-mtune=")) ||
- !strncmp(argv[i], "-mcpu=", strlen("-mcpu=" )))
- break;
- }
- if (i == argc) {
+ defined(BR_CPU)
+ /* Add our -march/cpu flags, but only if none of
+ * -march/mtune/mcpu are already specified on the commandline
+ */
+ for (i = 1; i < argc; i++) {
+ if (!strncmp(argv[i], "-march=", strlen("-march=")) ||
+ !strncmp(argv[i], "-mtune=", strlen("-mtune=")) ||
+ !strncmp(argv[i], "-mcpu=", strlen("-mcpu=" )))
+ break;
+ }
+ if (i == argc) {
#ifdef BR_ARCH
- *cur++ = "-march=" BR_ARCH;
+ *cur++ = "-march=" BR_ARCH;
#endif
#ifdef BR_CPU
- *cur++ = "-mcpu=" BR_CPU;
+ *cur++ = "-mcpu=" BR_CPU;
#endif
- }
+ }
#endif /* ARCH || CPU */
+ }
paranoid_wrapper = getenv("BR_COMPILER_PARANOID_UNSAFE_PATH");
if (paranoid_wrapper && strlen(paranoid_wrapper) > 0)
@@ -252,7 +276,7 @@ int main(int argc, char **argv)
exec_args = args;
#ifdef BR_CCACHE
- if (getenv("BR_NO_CCACHE"))
+ if (!ld_wrapper && getenv("BR_NO_CCACHE"))
/* Skip the ccache call */
exec_args++;
#endif
@@ -268,12 +292,14 @@ int main(int argc, char **argv)
if (debug > 0) {
fprintf(stderr, "Toolchain wrapper executing:");
#ifdef BR_CCACHE_HASH
- fprintf(stderr, "%sCCACHE_COMPILERCHECK='string:" BR_CCACHE_HASH "'",
- (debug == 2) ? "\n " : " ");
+ if(!ld_wrapper)
+ fprintf(stderr, "%sCCACHE_COMPILERCHECK='string:" BR_CCACHE_HASH "'",
+ (debug == 2) ? "\n " : " ");
#endif
#ifdef BR_CCACHE_BASEDIR
- fprintf(stderr, "%sCCACHE_BASEDIR='" BR_CCACHE_BASEDIR "'",
- (debug == 2) ? "\n " : " ");
+ if(!ld_wrapper)
+ fprintf(stderr, "%sCCACHE_BASEDIR='" BR_CCACHE_BASEDIR "'",
+ (debug == 2) ? "\n " : " ");
#endif
for (i = 0; exec_args[i]; i++)
fprintf(stderr, "%s'%s'",
@@ -284,14 +310,14 @@ int main(int argc, char **argv)
#ifdef BR_CCACHE_HASH
/* Allow compilercheck to be overridden through the environment */
- if (setenv("CCACHE_COMPILERCHECK", "string:" BR_CCACHE_HASH, 0)) {
+ if (!ld_wrapper && setenv("CCACHE_COMPILERCHECK", "string:" BR_CCACHE_HASH, 0)) {
perror(__FILE__ ": Failed to set CCACHE_COMPILERCHECK");
return 3;
}
#endif
#ifdef BR_CCACHE_BASEDIR
/* Allow compilercheck to be overridden through the environment */
- if (setenv("CCACHE_BASEDIR", BR_CCACHE_BASEDIR, 0)) {
+ if (!ld_wrapper && setenv("CCACHE_BASEDIR", BR_CCACHE_BASEDIR, 0)) {
perror(__FILE__ ": Failed to set CCACHE_BASEDIR");
return 3;
}
--
2.5.0
^ permalink raw reply related [flat|nested] 14+ messages in thread
* [Buildroot] [PATCH v2 2/4] toolchain: add option to specify ld emulation
2016-04-05 19:45 [Buildroot] [PATCH v2 1/4] toolchain: wrap 'ld' with toolchain-wrapper Jan Heylen
@ 2016-04-05 19:45 ` Jan Heylen
2016-04-05 19:45 ` [Buildroot] [PATCH v2 3/4] toolchain: add TARGET_LDFLAGS to toolchain-wrapper Jan Heylen
` (2 subsequent siblings)
3 siblings, 0 replies; 14+ messages in thread
From: Jan Heylen @ 2016-04-05 19:45 UTC (permalink / raw)
To: buildroot
On some architectures, such as MIPS, the linker supports several 'ld
emulation', and depending on which flavor of the architecture you're
building for, one should be passing the proper -m <something> option
to ld, otherwise ld defaults to the default emulation, which may not
necessarily be compatible with the object files that are being
linked.
Add this new option to the ld toolchain-wrapper.
Based upon patch from Thomas Petazzoni:
http://thread.gmane.org/gmane.comp.lib.uclibc.buildroot/60942
---
arch/Config.in | 3 +++
toolchain/toolchain-wrapper.c | 3 +++
toolchain/toolchain-wrapper.mk | 5 +++++
3 files changed, 11 insertions(+)
diff --git a/arch/Config.in b/arch/Config.in
index 3f1453f..3b022fe 100644
--- a/arch/Config.in
+++ b/arch/Config.in
@@ -265,6 +265,9 @@ config BR2_GCC_TARGET_CPU
config BR2_GCC_TARGET_CPU_REVISION
string
+config BR2_LD_TARGET_EMULATION
+ string
+
# The value of this option will be passed as --with-fpu=<value> when
# building gcc (internal backend) or -mfpu=<value> in the toolchain
# wrapper (external toolchain)
diff --git a/toolchain/toolchain-wrapper.c b/toolchain/toolchain-wrapper.c
index ec069da..8d1739c 100644
--- a/toolchain/toolchain-wrapper.c
+++ b/toolchain/toolchain-wrapper.c
@@ -82,6 +82,9 @@ static char *gcc_predef_args[] = {
static char *ld_predef_args[] = {
path,
+#ifdef BR_LD_EMULATION
+ "-m", BR_LD_EMULATION,
+#endif
#ifdef BR_BINFMT_FLAT
"-elf2flt",
#endif
diff --git a/toolchain/toolchain-wrapper.mk b/toolchain/toolchain-wrapper.mk
index af39071..f868fad 100644
--- a/toolchain/toolchain-wrapper.mk
+++ b/toolchain/toolchain-wrapper.mk
@@ -30,6 +30,11 @@ ifeq ($(BR2_CCACHE_USE_BASEDIR),y)
TOOLCHAIN_WRAPPER_ARGS += -DBR_CCACHE_BASEDIR='"$(BASE_DIR)"'
endif
+LD_TARGET_EMULATION_ = $(call qstrip,$(BR2_LD_TARGET_EMULATION))
+ifneq ($(LD_TARGET_EMULATION_),)
+TOOLCHAIN_WRAPPER_ARGS += -DBR_LD_EMULATION='"$(LD_TARGET_EMULATION_)"'
+endif
+
# For simplicity, build directly into the install location
define TOOLCHAIN_BUILD_WRAPPER
$(Q)mkdir -p $(HOST_DIR)/usr/bin
--
2.5.0
^ permalink raw reply related [flat|nested] 14+ messages in thread
* [Buildroot] [PATCH v2 3/4] toolchain: add TARGET_LDFLAGS to toolchain-wrapper
2016-04-05 19:45 [Buildroot] [PATCH v2 1/4] toolchain: wrap 'ld' with toolchain-wrapper Jan Heylen
2016-04-05 19:45 ` [Buildroot] [PATCH v2 2/4] toolchain: add option to specify ld emulation Jan Heylen
@ 2016-04-05 19:45 ` Jan Heylen
2016-04-05 19:45 ` [Buildroot] [PATCH v2 4/4] arch: define appropriate ld emulation values for the MIPS architecture Jan Heylen
2016-10-16 10:05 ` [Buildroot] [PATCH v2 1/4] toolchain: wrap 'ld' with toolchain-wrapper Thomas Petazzoni
3 siblings, 0 replies; 14+ messages in thread
From: Jan Heylen @ 2016-04-05 19:45 UTC (permalink / raw)
To: buildroot
only done for ld-wrapper, LDFLAGS is still set as before for gcc
---
toolchain/toolchain-wrapper.c | 3 +++
toolchain/toolchain-wrapper.mk | 8 ++++++--
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/toolchain/toolchain-wrapper.c b/toolchain/toolchain-wrapper.c
index 8d1739c..d6ecf84 100644
--- a/toolchain/toolchain-wrapper.c
+++ b/toolchain/toolchain-wrapper.c
@@ -94,6 +94,9 @@ static char *ld_predef_args[] = {
#if defined(BR_MIPS_TARGET_BIG_ENDIAN) || defined(BR_ARC_TARGET_BIG_ENDIAN)
"-EB",
#endif
+#ifdef BR_ADDITIONAL_LDFLAGS
+ BR_ADDITIONAL_LDFLAGS
+#endif
};
static void check_unsafe_path(const char *path, int paranoid)
diff --git a/toolchain/toolchain-wrapper.mk b/toolchain/toolchain-wrapper.mk
index f868fad..c7cc38e 100644
--- a/toolchain/toolchain-wrapper.mk
+++ b/toolchain/toolchain-wrapper.mk
@@ -14,9 +14,13 @@ TOOLCHAIN_WRAPPER_ARGS += -DBR_SYSROOT='"$(STAGING_SUBDIR)"'
# We create a list like '"-mfoo", "-mbar", "-mbarfoo"' so that each flag is a
# separate argument when used in execv() by the toolchain wrapper.
-TOOLCHAIN_WRAPPER_OPTS = \
+TOOLCHAIN_WRAPPER_CFLAGS_OPTS = \
$(foreach f,$(call qstrip,$(BR2_TARGET_OPTIMIZATION)),"$(f)"$(comma))
-TOOLCHAIN_WRAPPER_ARGS += -DBR_ADDITIONAL_CFLAGS='$(TOOLCHAIN_WRAPPER_OPTS)'
+TOOLCHAIN_WRAPPER_ARGS += -DBR_ADDITIONAL_CFLAGS='$(TOOLCHAIN_WRAPPER_CFLAGS_OPTS)'
+
+TOOLCHAIN_WRAPPER_LDFLAGS_OPTS = \
+ $(foreach f,$(subst -Wl$(comma),$(empty),$(call qstrip,$(BR2_TARGET_LDFLAGS))),"$(f)"$(comma))
+TOOLCHAIN_WRAPPER_ARGS += -DBR_ADDITIONAL_LDFLAGS='$(TOOLCHAIN_WRAPPER_LDFLAGS_OPTS)'
ifeq ($(BR2_CCACHE),y)
TOOLCHAIN_WRAPPER_ARGS += -DBR_CCACHE
--
2.5.0
^ permalink raw reply related [flat|nested] 14+ messages in thread
* [Buildroot] [PATCH v2 4/4] arch: define appropriate ld emulation values for the MIPS architecture
2016-04-05 19:45 [Buildroot] [PATCH v2 1/4] toolchain: wrap 'ld' with toolchain-wrapper Jan Heylen
2016-04-05 19:45 ` [Buildroot] [PATCH v2 2/4] toolchain: add option to specify ld emulation Jan Heylen
2016-04-05 19:45 ` [Buildroot] [PATCH v2 3/4] toolchain: add TARGET_LDFLAGS to toolchain-wrapper Jan Heylen
@ 2016-04-05 19:45 ` Jan Heylen
2016-10-16 10:05 ` [Buildroot] [PATCH v2 1/4] toolchain: wrap 'ld' with toolchain-wrapper Thomas Petazzoni
3 siblings, 0 replies; 14+ messages in thread
From: Jan Heylen @ 2016-04-05 19:45 UTC (permalink / raw)
To: buildroot
based upon patch from Thomas Petazzoni:
http://thread.gmane.org/gmane.comp.lib.uclibc.buildroot/60942
---
arch/Config.in.mips | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/Config.in.mips b/arch/Config.in.mips
index fda1a1d..37e4bf6 100644
--- a/arch/Config.in.mips
+++ b/arch/Config.in.mips
@@ -83,3 +83,11 @@ config BR2_GCC_TARGET_ABI
default "32" if BR2_MIPS_OABI32
default "n32" if BR2_MIPS_NABI32
default "64" if BR2_MIPS_NABI64
+
+config BR2_LD_TARGET_EMULATION
+ default "elf64ltsmip" if BR2_mips64el && BR2_MIPS_NABI64
+ default "elf64btsmip" if BR2_mips64 && BR2_MIPS_NABI64
+ default "elf32ltsmipn32" if BR2_mips64el && BR2_MIPS_NABI32
+ default "elf32btsmipn32" if BR2_mips64 && BR2_MIPS_NABI32
+ default "elf32ltsmip" if (BR2_mips64el && BR2_MIPS_OABI32) || BR2_mipsel
+ default "elf32btsmip" if (BR2_mips64 && BR2_MIPS_OABI32) || BR2_mips
--
2.5.0
^ permalink raw reply related [flat|nested] 14+ messages in thread
* [Buildroot] [PATCH v2 1/4] toolchain: wrap 'ld' with toolchain-wrapper
2016-04-05 19:45 [Buildroot] [PATCH v2 1/4] toolchain: wrap 'ld' with toolchain-wrapper Jan Heylen
` (2 preceding siblings ...)
2016-04-05 19:45 ` [Buildroot] [PATCH v2 4/4] arch: define appropriate ld emulation values for the MIPS architecture Jan Heylen
@ 2016-10-16 10:05 ` Thomas Petazzoni
2016-10-16 11:36 ` Jan Heylen
3 siblings, 1 reply; 14+ messages in thread
From: Thomas Petazzoni @ 2016-10-16 10:05 UTC (permalink / raw)
To: buildroot
Hello,
On Tue, 5 Apr 2016 21:45:18 +0200, Jan Heylen wrote:
> extend the toolchain wrapper to also wrap the ld linker.
>
> Tested with gnu ld and gnu 'gold'
> BR2_BINUTILS_EXTRA_CONFIG_OPTIONS="--enable-gold=default --enable-plugins"
>
> make host-binutils result in: (ld and ld.gold are equal)
> <ARCH>-buildroot-linux-uclibc-ld -> toolchain-wrapper
> <ARCH>-buildroot-linux-uclibc-ld.bfd
> <ARCH>-buildroot-linux-uclibc-ld.br_real
> <ARCH>-buildroot-linux-uclibc-ld.gold -> toolchain-wrapper
> <ARCH>-buildroot-linux-uclibc-ld.gold.br_real
> <ARCH>-linux-ld -> toolchain-wrapper
> <ARCH>-linux-ld.br_real -> <ARCH>-buildroot-linux-uclibc-ld.br_real
> <ARCH>-linux-ld.gold -> toolchain-wrapper
> <ARCH>-linux-ld.gold.br_real -> <ARCH>-buildroot-linux-uclibc-ld.gold.br_real
> toolchain-wrapper
>
> after host-gcc-initial, toolchain-wrapper will be rebuild, but the ld
> symlinks remain
>
> Based upon patch from Thomas Petazzoni:
> http://thread.gmane.org/gmane.comp.lib.uclibc.buildroot/60942
We had a discussion at the Buildroot Developers meeting today about
this patch series. After discussion, we concluded that there should be
no need to wrap ld. ld should not be used directly, except in very
specific cases, where the caller knows what it is doing and should pass
the right arguments.
As far as we know, the only case that was broken was the libiscsi
package, but such a package should definitely *not* use ld directly. So
the fix should be done in libiscsi, not in the wrapper.
However, your patch series triggered a very useful discussion about
reworking how flags are handled by the wrapper, and we took the
following notes of things to do:
- We want to refactor how the CFLAGS are handled by the wrapper:
- Combine BR2_TARGET_OPTIMIZATION and BR2_TARGET_LDFLAGS into a
single BR2_TARGET_EXTRA_FLAGS
- Have a make variable called TARGET_WRAPPER_FLAGS that includes
all flags we want to include in the wrapper:
* $(TARGET_ABI)
* $(TARGET_CPPFLAGS)
* $(BR2_TARGET_EXTRA_FLAGS)
* Custom flags added by package/Makefile.in
$(TARGET_OPTIMIZATION) and $(TARGET_DEBUGGING) are *NOT* in the
wrapper.
- TARGET_CFLAGS = $(TARGET_WRAPPER_CFLAGS) $(TARGET_OPTIMIZATION) $(TARGET_DEBUGGING)
TARGET_CXXFLAGS = $(TARGET_CFLAGS)
TARGET_LDFLAGS = $(TARGET_CFLAGS)
TARGET_FCFLAGS = $(TARGET_CFLAGS)
- The wrapper, instead of having special cases for different flags,
just receives (at build time), the list of hardcoded flag. A
special logic needs to be put in place to handle precious flags
(mcpu, march, mtune, mfloat-abi, etc.), for which the
command-line passed flag must be preserved if passed.
- Define LD to "false" in $(TARGET_CONFIGURE_OPTS) so that we detect
the crappy packages that use LD directly. Individual packages can
still pass LD=$(TARGET_LD) or LD=$(TARGET_CC) if really needed.
We're of course not asking you to work on those topics. Arnout has
volunteered to do it already.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Buildroot] [PATCH v2 1/4] toolchain: wrap 'ld' with toolchain-wrapper
2016-10-16 10:05 ` [Buildroot] [PATCH v2 1/4] toolchain: wrap 'ld' with toolchain-wrapper Thomas Petazzoni
@ 2016-10-16 11:36 ` Jan Heylen
2016-10-16 12:28 ` Thomas Petazzoni
0 siblings, 1 reply; 14+ messages in thread
From: Jan Heylen @ 2016-10-16 11:36 UTC (permalink / raw)
To: buildroot
So we should fix libdmalloc as well?
On 16 Oct 2016 12:05 pm, "Thomas Petazzoni" <
thomas.petazzoni@free-electrons.com> wrote:
> Hello,
>
> On Tue, 5 Apr 2016 21:45:18 +0200, Jan Heylen wrote:
> > extend the toolchain wrapper to also wrap the ld linker.
> >
> > Tested with gnu ld and gnu 'gold'
> > BR2_BINUTILS_EXTRA_CONFIG_OPTIONS="--enable-gold=default
> --enable-plugins"
> >
> > make host-binutils result in: (ld and ld.gold are equal)
> > <ARCH>-buildroot-linux-uclibc-ld -> toolchain-wrapper
> > <ARCH>-buildroot-linux-uclibc-ld.bfd
> > <ARCH>-buildroot-linux-uclibc-ld.br_real
> > <ARCH>-buildroot-linux-uclibc-ld.gold -> toolchain-wrapper
> > <ARCH>-buildroot-linux-uclibc-ld.gold.br_real
> > <ARCH>-linux-ld -> toolchain-wrapper
> > <ARCH>-linux-ld.br_real -> <ARCH>-buildroot-linux-uclibc-ld.br_real
> > <ARCH>-linux-ld.gold -> toolchain-wrapper
> > <ARCH>-linux-ld.gold.br_real -> <ARCH>-buildroot-linux-uclibc-
> ld.gold.br_real
> > toolchain-wrapper
> >
> > after host-gcc-initial, toolchain-wrapper will be rebuild, but the ld
> > symlinks remain
> >
> > Based upon patch from Thomas Petazzoni:
> > http://thread.gmane.org/gmane.comp.lib.uclibc.buildroot/60942
>
> We had a discussion at the Buildroot Developers meeting today about
> this patch series. After discussion, we concluded that there should be
> no need to wrap ld. ld should not be used directly, except in very
> specific cases, where the caller knows what it is doing and should pass
> the right arguments.
>
> As far as we know, the only case that was broken was the libiscsi
> package, but such a package should definitely *not* use ld directly. So
> the fix should be done in libiscsi, not in the wrapper.
>
> However, your patch series triggered a very useful discussion about
> reworking how flags are handled by the wrapper, and we took the
> following notes of things to do:
>
> - We want to refactor how the CFLAGS are handled by the wrapper:
>
> - Combine BR2_TARGET_OPTIMIZATION and BR2_TARGET_LDFLAGS into a
> single BR2_TARGET_EXTRA_FLAGS
>
> - Have a make variable called TARGET_WRAPPER_FLAGS that includes
> all flags we want to include in the wrapper:
>
> * $(TARGET_ABI)
> * $(TARGET_CPPFLAGS)
> * $(BR2_TARGET_EXTRA_FLAGS)
> * Custom flags added by package/Makefile.in
>
> $(TARGET_OPTIMIZATION) and $(TARGET_DEBUGGING) are *NOT* in the
> wrapper.
>
> - TARGET_CFLAGS = $(TARGET_WRAPPER_CFLAGS) $(TARGET_OPTIMIZATION)
> $(TARGET_DEBUGGING)
> TARGET_CXXFLAGS = $(TARGET_CFLAGS)
> TARGET_LDFLAGS = $(TARGET_CFLAGS)
> TARGET_FCFLAGS = $(TARGET_CFLAGS)
>
> - The wrapper, instead of having special cases for different flags,
> just receives (at build time), the list of hardcoded flag. A
> special logic needs to be put in place to handle precious flags
> (mcpu, march, mtune, mfloat-abi, etc.), for which the
> command-line passed flag must be preserved if passed.
>
> - Define LD to "false" in $(TARGET_CONFIGURE_OPTS) so that we detect
> the crappy packages that use LD directly. Individual packages can
> still pass LD=$(TARGET_LD) or LD=$(TARGET_CC) if really needed.
>
> We're of course not asking you to work on those topics. Arnout has
> volunteered to do it already.
>
> Best regards,
>
> Thomas
> --
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20161016/4cd466f6/attachment.html>
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Buildroot] [PATCH v2 1/4] toolchain: wrap 'ld' with toolchain-wrapper
2016-10-16 11:36 ` Jan Heylen
@ 2016-10-16 12:28 ` Thomas Petazzoni
2016-10-16 12:38 ` Vicente Olivert Riera
0 siblings, 1 reply; 14+ messages in thread
From: Thomas Petazzoni @ 2016-10-16 12:28 UTC (permalink / raw)
To: buildroot
Hello,
On Sun, 16 Oct 2016 13:36:19 +0200, Jan Heylen wrote:
> So we should fix libdmalloc as well?
Vicente is working on this. Do you have references to autobuilder
failures on libdmalloc caused by this problem ?
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Buildroot] [PATCH v2 1/4] toolchain: wrap 'ld' with toolchain-wrapper
2016-10-16 12:28 ` Thomas Petazzoni
@ 2016-10-16 12:38 ` Vicente Olivert Riera
2016-10-16 15:00 ` Jan Heylen
0 siblings, 1 reply; 14+ messages in thread
From: Vicente Olivert Riera @ 2016-10-16 12:38 UTC (permalink / raw)
To: buildroot
Hello Jan,
have you recently seen the dmalloc package failing because of using the
wrong emulation in ld? Or because using ld instead of gcc for linking,
in general?
Indeed it uses ld instead of gcc, and that's something that could be
improved upstream. However, since it's not failing to build for us I
think there is nothing we need to fix in Buildroot.
Regards,
Vincent.
On 16/10/16 14:28, Thomas Petazzoni wrote:
> Hello,
>
> On Sun, 16 Oct 2016 13:36:19 +0200, Jan Heylen wrote:
>> So we should fix libdmalloc as well?
>
> Vicente is working on this. Do you have references to autobuilder
> failures on libdmalloc caused by this problem ?
>
> Thanks!
>
> Thomas
>
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Buildroot] [PATCH v2 1/4] toolchain: wrap 'ld' with toolchain-wrapper
2016-10-16 12:38 ` Vicente Olivert Riera
@ 2016-10-16 15:00 ` Jan Heylen
2016-10-16 15:15 ` Vicente Olivert Riera
0 siblings, 1 reply; 14+ messages in thread
From: Jan Heylen @ 2016-10-16 15:00 UTC (permalink / raw)
To: buildroot
For our platform (mips octeon 64 bit but with 32bit userspace:
-mabi=n32), and indeed because of the usage of LD, the compilation
does fail, that is why I added the patches.
br,
Jan
On Sun, Oct 16, 2016 at 2:38 PM, Vicente Olivert Riera
<Vincent.Riera@imgtec.com> wrote:
> Hello Jan,
>
> have you recently seen the dmalloc package failing because of using the
> wrong emulation in ld? Or because using ld instead of gcc for linking,
> in general?
>
> Indeed it uses ld instead of gcc, and that's something that could be
> improved upstream. However, since it's not failing to build for us I
> think there is nothing we need to fix in Buildroot.
>
> Regards,
>
> Vincent.
>
> On 16/10/16 14:28, Thomas Petazzoni wrote:
>> Hello,
>>
>> On Sun, 16 Oct 2016 13:36:19 +0200, Jan Heylen wrote:
>>> So we should fix libdmalloc as well?
>>
>> Vicente is working on this. Do you have references to autobuilder
>> failures on libdmalloc caused by this problem ?
>>
>> Thanks!
>>
>> Thomas
>>
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Buildroot] [PATCH v2 1/4] toolchain: wrap 'ld' with toolchain-wrapper
2016-10-16 15:00 ` Jan Heylen
@ 2016-10-16 15:15 ` Vicente Olivert Riera
2016-10-16 15:19 ` Jan Heylen
0 siblings, 1 reply; 14+ messages in thread
From: Vicente Olivert Riera @ 2016-10-16 15:15 UTC (permalink / raw)
To: buildroot
Hello Jan,
I have just built the dmalloc package for mips64r2 n32 little-endian and
big-endian without any issue. I have used the "Codescape MTI" external
toolchain. Are you using a different toolchain? Please let me know so I
can reproduce the problem.
Regards,
Vincent.
On 16/10/16 17:00, Jan Heylen wrote:
> For our platform (mips octeon 64 bit but with 32bit userspace:
> -mabi=n32), and indeed because of the usage of LD, the compilation
> does fail, that is why I added the patches.
>
> br,
>
> Jan
>
> On Sun, Oct 16, 2016 at 2:38 PM, Vicente Olivert Riera
> <Vincent.Riera@imgtec.com> wrote:
>> Hello Jan,
>>
>> have you recently seen the dmalloc package failing because of using the
>> wrong emulation in ld? Or because using ld instead of gcc for linking,
>> in general?
>>
>> Indeed it uses ld instead of gcc, and that's something that could be
>> improved upstream. However, since it's not failing to build for us I
>> think there is nothing we need to fix in Buildroot.
>>
>> Regards,
>>
>> Vincent.
>>
>> On 16/10/16 14:28, Thomas Petazzoni wrote:
>>> Hello,
>>>
>>> On Sun, 16 Oct 2016 13:36:19 +0200, Jan Heylen wrote:
>>>> So we should fix libdmalloc as well?
>>>
>>> Vicente is working on this. Do you have references to autobuilder
>>> failures on libdmalloc caused by this problem ?
>>>
>>> Thanks!
>>>
>>> Thomas
>>>
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Buildroot] [PATCH v2 1/4] toolchain: wrap 'ld' with toolchain-wrapper
2016-10-16 15:15 ` Vicente Olivert Riera
@ 2016-10-16 15:19 ` Jan Heylen
2016-10-16 15:33 ` Vicente Olivert Riera
0 siblings, 1 reply; 14+ messages in thread
From: Jan Heylen @ 2016-10-16 15:19 UTC (permalink / raw)
To: buildroot
I'm using a toolchain coming from Cavium, so you're saying that either
the toolchain is the issue or it is no longer an issue? It's been some
time ago that I tested this, let me come back to you later this week.
br,
Jan
On Sun, Oct 16, 2016 at 5:15 PM, Vicente Olivert Riera
<Vincent.Riera@imgtec.com> wrote:
> Hello Jan,
>
> I have just built the dmalloc package for mips64r2 n32 little-endian and
> big-endian without any issue. I have used the "Codescape MTI" external
> toolchain. Are you using a different toolchain? Please let me know so I
> can reproduce the problem.
>
> Regards,
>
> Vincent.
>
> On 16/10/16 17:00, Jan Heylen wrote:
>> For our platform (mips octeon 64 bit but with 32bit userspace:
>> -mabi=n32), and indeed because of the usage of LD, the compilation
>> does fail, that is why I added the patches.
>>
>> br,
>>
>> Jan
>>
>> On Sun, Oct 16, 2016 at 2:38 PM, Vicente Olivert Riera
>> <Vincent.Riera@imgtec.com> wrote:
>>> Hello Jan,
>>>
>>> have you recently seen the dmalloc package failing because of using the
>>> wrong emulation in ld? Or because using ld instead of gcc for linking,
>>> in general?
>>>
>>> Indeed it uses ld instead of gcc, and that's something that could be
>>> improved upstream. However, since it's not failing to build for us I
>>> think there is nothing we need to fix in Buildroot.
>>>
>>> Regards,
>>>
>>> Vincent.
>>>
>>> On 16/10/16 14:28, Thomas Petazzoni wrote:
>>>> Hello,
>>>>
>>>> On Sun, 16 Oct 2016 13:36:19 +0200, Jan Heylen wrote:
>>>>> So we should fix libdmalloc as well?
>>>>
>>>> Vicente is working on this. Do you have references to autobuilder
>>>> failures on libdmalloc caused by this problem ?
>>>>
>>>> Thanks!
>>>>
>>>> Thomas
>>>>
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Buildroot] [PATCH v2 1/4] toolchain: wrap 'ld' with toolchain-wrapper
2016-10-16 15:19 ` Jan Heylen
@ 2016-10-16 15:33 ` Vicente Olivert Riera
2016-10-16 17:27 ` Jan Heylen
0 siblings, 1 reply; 14+ messages in thread
From: Vicente Olivert Riera @ 2016-10-16 15:33 UTC (permalink / raw)
To: buildroot
On 16/10/16 17:19, Jan Heylen wrote:
> I'm using a toolchain coming from Cavium, so you're saying that either
> the toolchain is the issue or it is no longer an issue? It's been some
> time ago that I tested this, let me come back to you later this week.
Ok. Just for the record, no problem with the buildroot internal
toolchain either. dmalloc built for mips64r2 n32 little-endian uclibc-ng.
Regards,
Vincent.
> br,
>
> Jan
>
> On Sun, Oct 16, 2016 at 5:15 PM, Vicente Olivert Riera
> <Vincent.Riera@imgtec.com> wrote:
>> Hello Jan,
>>
>> I have just built the dmalloc package for mips64r2 n32 little-endian and
>> big-endian without any issue. I have used the "Codescape MTI" external
>> toolchain. Are you using a different toolchain? Please let me know so I
>> can reproduce the problem.
>>
>> Regards,
>>
>> Vincent.
>>
>> On 16/10/16 17:00, Jan Heylen wrote:
>>> For our platform (mips octeon 64 bit but with 32bit userspace:
>>> -mabi=n32), and indeed because of the usage of LD, the compilation
>>> does fail, that is why I added the patches.
>>>
>>> br,
>>>
>>> Jan
>>>
>>> On Sun, Oct 16, 2016 at 2:38 PM, Vicente Olivert Riera
>>> <Vincent.Riera@imgtec.com> wrote:
>>>> Hello Jan,
>>>>
>>>> have you recently seen the dmalloc package failing because of using the
>>>> wrong emulation in ld? Or because using ld instead of gcc for linking,
>>>> in general?
>>>>
>>>> Indeed it uses ld instead of gcc, and that's something that could be
>>>> improved upstream. However, since it's not failing to build for us I
>>>> think there is nothing we need to fix in Buildroot.
>>>>
>>>> Regards,
>>>>
>>>> Vincent.
>>>>
>>>> On 16/10/16 14:28, Thomas Petazzoni wrote:
>>>>> Hello,
>>>>>
>>>>> On Sun, 16 Oct 2016 13:36:19 +0200, Jan Heylen wrote:
>>>>>> So we should fix libdmalloc as well?
>>>>>
>>>>> Vicente is working on this. Do you have references to autobuilder
>>>>> failures on libdmalloc caused by this problem ?
>>>>>
>>>>> Thanks!
>>>>>
>>>>> Thomas
>>>>>
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Buildroot] [PATCH v2 1/4] toolchain: wrap 'ld' with toolchain-wrapper
2016-10-16 15:33 ` Vicente Olivert Riera
@ 2016-10-16 17:27 ` Jan Heylen
2016-10-24 6:00 ` Jan Heylen
0 siblings, 1 reply; 14+ messages in thread
From: Jan Heylen @ 2016-10-16 17:27 UTC (permalink / raw)
To: buildroot
Hi,
ok, I just realized I won't have time 'later this week', so I had a look at
this again right away (#GTD it is called in hipster language). Did you
check the output of the build for dmalloc? I just verified the issue with
our toolchain, and the result is indeed that dmalloc 'builds', but if you
look at the .so file:
-rw-r--r-- 1 jheylen we2 849476 16 okt 19:04 libdmalloc.a
-rwxr-xr-x 1 jheylen we2 593 16 okt 19:04 libdmalloc.so
-rwxr-xr-x 1 jheylen we2 593 16 okt 19:05 libdmalloc.so.t
-rw-r--r-- 1 jheylen we2 858132 16 okt 19:04 libdmallocth.a
-rw-r--r-- 1 jheylen we2 915054 16 okt 19:04 libdmallocthcxx.a
-rwxr-xr-x 1 jheylen we2 593 16 okt 19:04 libdmallocthcxx.so
-rwxr-xr-x 1 jheylen we2 593 16 okt 19:04 libdmallocth.so
-rw-r--r-- 1 jheylen we2 906398 16 okt 19:04 libdmallocxx.a
-rwxr-xr-x 1 jheylen we2 593 16 okt 19:04 libdmallocxx.so
The sizes look suspicious ;-), if I try them on target, it doesn't work,
and readelf -a libdmalloc.so:
----------------------------
ELF Header:
Magic: 7f 45 4c 46 02 02 01 00 00 00 00 00 00 00 00 00
Class: ELF64
Data: 2's complement, big endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: DYN (Shared object file)
Machine: MIPS R3000
Version: 0x1
Entry point address: 0x40
Start of program headers: 0 (bytes into file)
Start of section headers: 96 (bytes into file)
Flags: 0x0
Size of this header: 64 (bytes)
Size of program headers: 0 (bytes)
Number of program headers: 0
Size of section headers: 64 (bytes)
Number of section headers: 4
Section header string table index: 1
Section Headers:
[Nr] Name Type Address Offset
Size EntSize Flags Link Info Align
[ 0] NULL 0000000000000000 00000000
0000000000000000 0000000000000000 0 0 0
[ 1] .shstrtab STRTAB 0000000000000000 00000040
000000000000001b 0000000000000000 0 0 1
[ 2] .symtab SYMTAB 0000000000000000 00000160
00000000000000c0 0000000000000018 3 2 8
[ 3] .strtab STRTAB 0000000000000000 00000220
0000000000000031 0000000000000000 0 0 1
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings)
I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown)
O (extra OS processing required) o (OS specific), p (processor specific)
There are no section groups in this file.
There are no program headers in this file.
There are no relocations in this file.
The decoding of unwind sections for machine type MIPS R3000 is not
currently supported.
Symbol table '.symtab' contains 8 entries:
Num: Value Size Type Bind Vis Ndx Name
0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND
1: 0000000000018030 0 NOTYPE LOCAL DEFAULT ABS _gp
2: 0000000000010040 0 NOTYPE GLOBAL DEFAULT ABS _fdata
3: 0000000000000040 0 NOTYPE GLOBAL DEFAULT ABS _ftext
4: 0000000000010040 0 NOTYPE GLOBAL DEFAULT ABS __bss_start
5: 0000000000010040 0 NOTYPE GLOBAL DEFAULT ABS _edata
6: 0000000000010040 0 NOTYPE GLOBAL DEFAULT ABS _end
7: 0000000000010040 0 NOTYPE GLOBAL DEFAULT ABS _fbss
No version information found in this file.
----------------------------
from configure log and config.log, you see why dmalloc decides to link with
-G -o:
checking shared library link args...
<buildroot>/output/host/usr/bin/mips64-octeon-linux-gnu-ld -G -o $@.t
checking shared library extension... so
<buildroot>/output/host/usr/bin/mips64-octeon-linux-gnu-ld:
conftest.a(conftest.o): ABI is incompatible with that of the selected
emulation: "elf32-ntradbigmips" != "elf64- tradbigmips"
<buildroot>/output/host/usr/bin/mips64-octeon-linux-gnu-ld: failed to
merge target specific data of file conftest.a(conftest.o)
<buildroot>/output/host/usr/bin/mips64-octeon-linux-gnu-ld: unrecognized
option '-all'
<buildroot>/output/host/usr/bin/mips64-octeon-linux-gnu-ld: use the
--help option for usage information
444 configure:4475:
result: <buildroot>/output/host/usr/bin/mips64-octeon-linux-gnu-ld -G -o
$@.t
from an earlier conversation on the subject:
If I patch dmalloc.mk: (to test the underlying issue):
-DMALLOC_CONF_ENV = CFLAGS="$(DMALLOC_CFLAGS)"
+DMALLOC_CONF_ENV = CFLAGS="$(DMALLOC_CFLAGS)"
TARGET_LD="$(TARGET_LD) -m elf32btsmipn32 "
define DMALLOC_POST_PATCH
$(SED) 's/^ac_cv_page_size=0$$/ac_cv_page_size=12/' $(@D)/configure
- $(SED) 's/(ld -/($${LD-ld} -/' $(@D)/configure
- $(SED) 's/'\''ld -/"$${LD-ld}"'\'' -/' $(@D)/configure
+ $(SED) 's/(ld -/($${TARGET_LD-ld} -/' $(@D)/configure
+ $(SED) 's/'\''ld -/"$${TARGET_LD-ld}"'\'' -/' $(@D)/configure
$(SED) 's/ar cr/$$(AR) cr/' $(@D)/Makefile.in
endef
I found in the config.log:
configure:4475: result:
/repo/buildroot-ngsw/output/host/usr/bin/mips64-octeon-linux-gnu-ld -m
elf32btsmipn32 -shared --whole-archive -soname $@ -o $@.t
which is what was expected.
Can you verify this in your referred toolchains and dmalloc builds?
thx,
Jan
On Sun, Oct 16, 2016 at 5:33 PM, Vicente Olivert Riera <
Vincent.Riera@imgtec.com> wrote:
> On 16/10/16 17:19, Jan Heylen wrote:
> > I'm using a toolchain coming from Cavium, so you're saying that either
> > the toolchain is the issue or it is no longer an issue? It's been some
> > time ago that I tested this, let me come back to you later this week.
>
> Ok. Just for the record, no problem with the buildroot internal
> toolchain either. dmalloc built for mips64r2 n32 little-endian uclibc-ng.
>
> Regards,
>
> Vincent.
>
> > br,
> >
> > Jan
> >
> > On Sun, Oct 16, 2016 at 5:15 PM, Vicente Olivert Riera
> > <Vincent.Riera@imgtec.com> wrote:
> >> Hello Jan,
> >>
> >> I have just built the dmalloc package for mips64r2 n32 little-endian and
> >> big-endian without any issue. I have used the "Codescape MTI" external
> >> toolchain. Are you using a different toolchain? Please let me know so I
> >> can reproduce the problem.
> >>
> >> Regards,
> >>
> >> Vincent.
> >>
> >> On 16/10/16 17:00, Jan Heylen wrote:
> >>> For our platform (mips octeon 64 bit but with 32bit userspace:
> >>> -mabi=n32), and indeed because of the usage of LD, the compilation
> >>> does fail, that is why I added the patches.
> >>>
> >>> br,
> >>>
> >>> Jan
> >>>
> >>> On Sun, Oct 16, 2016 at 2:38 PM, Vicente Olivert Riera
> >>> <Vincent.Riera@imgtec.com> wrote:
> >>>> Hello Jan,
> >>>>
> >>>> have you recently seen the dmalloc package failing because of using
> the
> >>>> wrong emulation in ld? Or because using ld instead of gcc for linking,
> >>>> in general?
> >>>>
> >>>> Indeed it uses ld instead of gcc, and that's something that could be
> >>>> improved upstream. However, since it's not failing to build for us I
> >>>> think there is nothing we need to fix in Buildroot.
> >>>>
> >>>> Regards,
> >>>>
> >>>> Vincent.
> >>>>
> >>>> On 16/10/16 14:28, Thomas Petazzoni wrote:
> >>>>> Hello,
> >>>>>
> >>>>> On Sun, 16 Oct 2016 13:36:19 +0200, Jan Heylen wrote:
> >>>>>> So we should fix libdmalloc as well?
> >>>>>
> >>>>> Vicente is working on this. Do you have references to autobuilder
> >>>>> failures on libdmalloc caused by this problem ?
> >>>>>
> >>>>> Thanks!
> >>>>>
> >>>>> Thomas
> >>>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20161016/48ed5b5d/attachment.html>
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Buildroot] [PATCH v2 1/4] toolchain: wrap 'ld' with toolchain-wrapper
2016-10-16 17:27 ` Jan Heylen
@ 2016-10-24 6:00 ` Jan Heylen
0 siblings, 0 replies; 14+ messages in thread
From: Jan Heylen @ 2016-10-24 6:00 UTC (permalink / raw)
To: buildroot
Hi Vincent,
any update on the libdmalloc issue we observe when building for MIPS
(because of no ld wrapper) ? Do you see the same?
br,
Jan
On Sun, Oct 16, 2016 at 7:27 PM, Jan Heylen <heyleke@gmail.com> wrote:
> Hi,
>
> ok, I just realized I won't have time 'later this week', so I had a look
> at this again right away (#GTD it is called in hipster language). Did you
> check the output of the build for dmalloc? I just verified the issue with
> our toolchain, and the result is indeed that dmalloc 'builds', but if you
> look at the .so file:
>
> -rw-r--r-- 1 jheylen we2 849476 16 okt 19:04 libdmalloc.a
> -rwxr-xr-x 1 jheylen we2 593 16 okt 19:04 libdmalloc.so
> -rwxr-xr-x 1 jheylen we2 593 16 okt 19:05 libdmalloc.so.t
> -rw-r--r-- 1 jheylen we2 858132 16 okt 19:04 libdmallocth.a
> -rw-r--r-- 1 jheylen we2 915054 16 okt 19:04 libdmallocthcxx.a
> -rwxr-xr-x 1 jheylen we2 593 16 okt 19:04 libdmallocthcxx.so
> -rwxr-xr-x 1 jheylen we2 593 16 okt 19:04 libdmallocth.so
> -rw-r--r-- 1 jheylen we2 906398 16 okt 19:04 libdmallocxx.a
> -rwxr-xr-x 1 jheylen we2 593 16 okt 19:04 libdmallocxx.so
>
> The sizes look suspicious ;-), if I try them on target, it doesn't work,
> and readelf -a libdmalloc.so:
> ----------------------------
> ELF Header:
> Magic: 7f 45 4c 46 02 02 01 00 00 00 00 00 00 00 00 00
> Class: ELF64
> Data: 2's complement, big endian
> Version: 1 (current)
> OS/ABI: UNIX - System V
> ABI Version: 0
> Type: DYN (Shared object file)
> Machine: MIPS R3000
> Version: 0x1
> Entry point address: 0x40
> Start of program headers: 0 (bytes into file)
> Start of section headers: 96 (bytes into file)
> Flags: 0x0
> Size of this header: 64 (bytes)
> Size of program headers: 0 (bytes)
> Number of program headers: 0
> Size of section headers: 64 (bytes)
> Number of section headers: 4
> Section header string table index: 1
>
> Section Headers:
> [Nr] Name Type Address Offset
> Size EntSize Flags Link Info Align
> [ 0] NULL 0000000000000000 00000000
> 0000000000000000 0000000000000000 0 0 0
> [ 1] .shstrtab STRTAB 0000000000000000 00000040
> 000000000000001b 0000000000000000 0 0 1
> [ 2] .symtab SYMTAB 0000000000000000 00000160
> 00000000000000c0 0000000000000018 3 2 8
> [ 3] .strtab STRTAB 0000000000000000 00000220
> 0000000000000031 0000000000000000 0 0 1
> Key to Flags:
> W (write), A (alloc), X (execute), M (merge), S (strings)
> I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown)
> O (extra OS processing required) o (OS specific), p (processor specific)
>
> There are no section groups in this file.
>
> There are no program headers in this file.
>
> There are no relocations in this file.
>
> The decoding of unwind sections for machine type MIPS R3000 is not
> currently supported.
>
> Symbol table '.symtab' contains 8 entries:
> Num: Value Size Type Bind Vis Ndx Name
> 0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND
> 1: 0000000000018030 0 NOTYPE LOCAL DEFAULT ABS _gp
> 2: 0000000000010040 0 NOTYPE GLOBAL DEFAULT ABS _fdata
> 3: 0000000000000040 0 NOTYPE GLOBAL DEFAULT ABS _ftext
> 4: 0000000000010040 0 NOTYPE GLOBAL DEFAULT ABS __bss_start
> 5: 0000000000010040 0 NOTYPE GLOBAL DEFAULT ABS _edata
> 6: 0000000000010040 0 NOTYPE GLOBAL DEFAULT ABS _end
> 7: 0000000000010040 0 NOTYPE GLOBAL DEFAULT ABS _fbss
>
> No version information found in this file.
> ----------------------------
>
> from configure log and config.log, you see why dmalloc decides to link
> with -G -o:
>
> checking shared library link args... <buildroot>/output/host/usr/bin/mips64-octeon-linux-gnu-ld
> -G -o $@.t
> checking shared library extension... so
>
> <buildroot>/output/host/usr/bin/mips64-octeon-linux-gnu-ld:
> conftest.a(conftest.o): ABI is incompatible with that of the selected
> emulation: "elf32-ntradbigmips" != "elf64- tradbigmips"
> <buildroot>/output/host/usr/bin/mips64-octeon-linux-gnu-ld: failed to
> merge target specific data of file conftest.a(conftest.o)
> <buildroot>/output/host/usr/bin/mips64-octeon-linux-gnu-ld: unrecognized
> option '-all'
> <buildroot>/output/host/usr/bin/mips64-octeon-linux-gnu-ld: use the
> --help option for usage information
> 444 configure:4475: result: <buildroot>/output/
> host/usr/bin/mips64-octeon-linux-gnu-ld -G -o $@.t
>
>
>
> from an earlier conversation on the subject:
>
> If I patch dmalloc.mk: (to test the underlying issue):
>
> -DMALLOC_CONF_ENV = CFLAGS="$(DMALLOC_CFLAGS)"
> +DMALLOC_CONF_ENV = CFLAGS="$(DMALLOC_CFLAGS)"
> TARGET_LD="$(TARGET_LD) -m elf32btsmipn32 "
>
> define DMALLOC_POST_PATCH
> $(SED) 's/^ac_cv_page_size=0$$/ac_cv_page_size=12/'
> $(@D)/configure
> - $(SED) 's/(ld -/($${LD-ld} -/' $(@D)/configure
> - $(SED) 's/'\''ld -/"$${LD-ld}"'\'' -/' $(@D)/configure
> + $(SED) 's/(ld -/($${TARGET_LD-ld} -/' $(@D)/configure
> + $(SED) 's/'\''ld -/"$${TARGET_LD-ld}"'\'' -/' $(@D)/configure
> $(SED) 's/ar cr/$$(AR) cr/' $(@D)/Makefile.in
> endef
>
> I found in the config.log:
> configure:4475: result:
> /repo/buildroot-ngsw/output/host/usr/bin/mips64-octeon-linux-gnu-ld -m
> elf32btsmipn32 -shared --whole-archive -soname $@ -o $@.t
>
> which is what was expected.
>
>
> Can you verify this in your referred toolchains and dmalloc builds?
>
> thx,
>
> Jan
>
> On Sun, Oct 16, 2016 at 5:33 PM, Vicente Olivert Riera <
> Vincent.Riera at imgtec.com> wrote:
>
>> On 16/10/16 17:19, Jan Heylen wrote:
>> > I'm using a toolchain coming from Cavium, so you're saying that either
>> > the toolchain is the issue or it is no longer an issue? It's been some
>> > time ago that I tested this, let me come back to you later this week.
>>
>> Ok. Just for the record, no problem with the buildroot internal
>> toolchain either. dmalloc built for mips64r2 n32 little-endian uclibc-ng.
>>
>> Regards,
>>
>> Vincent.
>>
>> > br,
>> >
>> > Jan
>> >
>> > On Sun, Oct 16, 2016 at 5:15 PM, Vicente Olivert Riera
>> > <Vincent.Riera@imgtec.com> wrote:
>> >> Hello Jan,
>> >>
>> >> I have just built the dmalloc package for mips64r2 n32 little-endian
>> and
>> >> big-endian without any issue. I have used the "Codescape MTI" external
>> >> toolchain. Are you using a different toolchain? Please let me know so I
>> >> can reproduce the problem.
>> >>
>> >> Regards,
>> >>
>> >> Vincent.
>> >>
>> >> On 16/10/16 17:00, Jan Heylen wrote:
>> >>> For our platform (mips octeon 64 bit but with 32bit userspace:
>> >>> -mabi=n32), and indeed because of the usage of LD, the compilation
>> >>> does fail, that is why I added the patches.
>> >>>
>> >>> br,
>> >>>
>> >>> Jan
>> >>>
>> >>> On Sun, Oct 16, 2016 at 2:38 PM, Vicente Olivert Riera
>> >>> <Vincent.Riera@imgtec.com> wrote:
>> >>>> Hello Jan,
>> >>>>
>> >>>> have you recently seen the dmalloc package failing because of using
>> the
>> >>>> wrong emulation in ld? Or because using ld instead of gcc for
>> linking,
>> >>>> in general?
>> >>>>
>> >>>> Indeed it uses ld instead of gcc, and that's something that could be
>> >>>> improved upstream. However, since it's not failing to build for us I
>> >>>> think there is nothing we need to fix in Buildroot.
>> >>>>
>> >>>> Regards,
>> >>>>
>> >>>> Vincent.
>> >>>>
>> >>>> On 16/10/16 14:28, Thomas Petazzoni wrote:
>> >>>>> Hello,
>> >>>>>
>> >>>>> On Sun, 16 Oct 2016 13:36:19 +0200, Jan Heylen wrote:
>> >>>>>> So we should fix libdmalloc as well?
>> >>>>>
>> >>>>> Vicente is working on this. Do you have references to autobuilder
>> >>>>> failures on libdmalloc caused by this problem ?
>> >>>>>
>> >>>>> Thanks!
>> >>>>>
>> >>>>> Thomas
>> >>>>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20161024/66cc098d/attachment.html>
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2016-10-24 6:00 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-04-05 19:45 [Buildroot] [PATCH v2 1/4] toolchain: wrap 'ld' with toolchain-wrapper Jan Heylen
2016-04-05 19:45 ` [Buildroot] [PATCH v2 2/4] toolchain: add option to specify ld emulation Jan Heylen
2016-04-05 19:45 ` [Buildroot] [PATCH v2 3/4] toolchain: add TARGET_LDFLAGS to toolchain-wrapper Jan Heylen
2016-04-05 19:45 ` [Buildroot] [PATCH v2 4/4] arch: define appropriate ld emulation values for the MIPS architecture Jan Heylen
2016-10-16 10:05 ` [Buildroot] [PATCH v2 1/4] toolchain: wrap 'ld' with toolchain-wrapper Thomas Petazzoni
2016-10-16 11:36 ` Jan Heylen
2016-10-16 12:28 ` Thomas Petazzoni
2016-10-16 12:38 ` Vicente Olivert Riera
2016-10-16 15:00 ` Jan Heylen
2016-10-16 15:15 ` Vicente Olivert Riera
2016-10-16 15:19 ` Jan Heylen
2016-10-16 15:33 ` Vicente Olivert Riera
2016-10-16 17:27 ` Jan Heylen
2016-10-24 6:00 ` Jan Heylen
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.