Re: Build regressions/improvements in v4.8-rc1
On Mon, Aug 8, 2016 at 10:32 AM, Geert Uytterhoeven
wrote:
> Below is the list of build error/warning regressions/improvements in
> v4.8-rc1[1] compared to v4.7[2].
>
> Summarized:
> - build errors: +8/-12
> + /home/kisskb/slave/src/arch/arm/kernel/setup.c: error: 'SECTION_SIZE'
> undeclared (first use in this function): => 1003:25
arm-randconfig
> + error: "__ucmpdi2" [drivers/scsi/sd_mod.ko] undefined!: => N/A
bfin/CM-BF548_defconfig
> + error: /home/kisskb/slave/src/drivers/block/loop.c: undefined reference
> to `__ucmpdi2': => .text+0x3aaee), .text+0x2ee10), .text+0x2ee1c)
> + error: /home/kisskb/slave/src/drivers/scsi/sd.c: undefined reference to
> `__ucmpdi2': => .text+0x36cb8), .text+0x3865c)
Various blackfin
> + error: No rule to make target arch/sh/boot/dts/.dtb.o: => N/A
sh-allyesconfig, sh-allmodconfig
> + {standard input}: Error: Instruction with long immediate data in delay
> slot: => 18728
arcv2/axs103_smp_defconfig
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: Build regressions/improvements in v4.8-rc1
Hi Geert,
On 08/08/2016 01:38 AM, Geert Uytterhoeven wrote:
>> + {standard input}: Error: Instruction with long immediate data in delay
>> slot: => 18728
> arcv2/axs103_smp_defconfig
What build service/farm does this use. Recently Guenter ran into this too and
updated his toolchain to work around the gcc bug.
-Vineet
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: Problems building arc-2016.09-eng007 toolchain with 2.6.35 kernel headers
On 08/08/2016 02:44 PM, Petri Gynther wrote: > uclibc-ng & ARC developers: > > I'm trying to use buildroot to build the latest ARC toolchain > (arc-2016.09-eng007) against our vendor-provided 2.6.35.12 ARC Linux > kernel. (Yes, it is an ancient kernel, but that's what I have to work > with for now, unfortunately.) > > ... > > > Questions: > 1) Does the latest ARC toolchain use some new ABI for binaries that > makes them incompatible with 2.6.35.12 kernel? Indeed even if you were to build it successfully - you will run into ABI issues - 2.6.35 is ABI v1 and we are currently at v3 (which is going to change soon even further to v4 - for ARC HS processors) More details at: https://github.com/foss-for-synopsys-dwc-arc-processors/linux/wiki/ARC-Linux-Syscall-ABI-Compatibility > 2) Is uclibc-ng 1.0.17 supposed to be compatible with 2.6.x kernel headers? No - modern/upstream uClibc-ng is not compatible with 2.6.35 You need to use the uClibc of the time - with pairing gcc/binutils - although that will be a can of worms > Any help is greatly appreciated. Thanks. Sorry - can't help you much here ! -Vineet ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH] ARC: Support R_ARC_JMP_SLOT relocations during bootstrap
On 07/28/2016 10:59 AM, Andrew Burgess wrote:
> I ran into this issue while trying to debug a _different_ issue witin
> the uClinc(-ng) arc dynamic linker. I turned on debugging support
> within the dynamic linker, and the linker would no longer complete its
> bootstrap phase due to a lack of support for the R_ARC_JMP_SLOT
> relocation type.
>
> To reproduce this issue it should be enough to configure uClibc(-ng)
> for ARC with 'DODEBUG=y', then try to run anything that requires
> dynamic linking.
>
> The R_ARC_JMP_SLOT relocation type is used within the .plt, so I
> believe it makes sense for these relocations to be generated.
>
> I updated the associated comment above the boostrap patching code so
> that it makes more sense (to me at least) with the extra relocation
> support.
>
> I wonder if you would consider merging this patch?
>
> Thanks,
> Andrew
>
>
> ---
>
> This commit adds support for R_ARC_JMP_SLOT relocations during the
> bootstrap phase of the dynamic linker. These relocations will be
> generated if uClibc is configured with 'DODEBUG=y'.
> ---
> ldso/ldso/arc/dl-startup.h | 11 +++
> 1 file changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/ldso/ldso/arc/dl-startup.h b/ldso/ldso/arc/dl-startup.h
> index ef89b53..fadc433 100644
> --- a/ldso/ldso/arc/dl-startup.h
> +++ b/ldso/ldso/arc/dl-startup.h
> @@ -64,10 +64,11 @@ __asm__(
>
> /*
> * Dynamic loader bootstrapping:
> - * Since we don't modify text at runtime, these can only be data relos
> - * (so safe to assume that they are word aligned).
> - * And also they HAVE to be RELATIVE relos only
> - * @RELP is the relo entry being processed
> + * The only relocations that should be found are either R_ARC_RELATIVE for
> + * data relocations (.got, etc) or R_ARC_JMP_SLOT for code relocations
> + * (.plt). It is safe to assume that all of these relocations are word
> + * aligned.
> + * @RELP is the reloc entry being processed
> * @REL is the pointer to the address we are relocating.
> * @SYMBOL is the symbol involved in the relocation
> * @LOAD is the load address.
> @@ -78,6 +79,8 @@ do {
> \
> int type = ELF32_R_TYPE((RELP)->r_info);\
> if (likely(type == R_ARC_RELATIVE)) \
> *REL += (unsigned long) LOAD; \
> + else if (type == R_ARC_JMP_SLOT)\
> + *REL = SYMBOL; \
> else\
> _dl_exit(1);\
> }while(0)
So I know this has been merged and all - but I'm wondering if this is PIE safe.
Cuper has been painfully fixing PIE related issues - including uClibc issues and
since we are on the topic I'm wondering if this needs some additional fixup ?
-Vineet
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
