[PATCH] arc: arcv1: Disable master/slave check
ARCompact cores are not supposed to be used in SMP designs (this doesn't stop people from creation of heterogeneous chips, for an example keep reading) so there's no point in checking ARCNUM and halting somebody if we build for ARC700. Moreover on AXS101 board we have ARC770 in the ASIC together with other ARC cores and ARC770 happens to be the last node in JTAG chain with ARCNUM = 4. And existing check halts the one and only core we want keep running. Signed-off-by: Alexey Brodkin --- arch/arc/lib/start.S | 4 1 file changed, 4 insertions(+) diff --git a/arch/arc/lib/start.S b/arch/arc/lib/start.S index b2ba7683097f..95d64f9d4375 100644 --- a/arch/arc/lib/start.S +++ b/arch/arc/lib/start.S @@ -10,6 +10,9 @@ #include ENTRY(_start) +; ARCompact devices are not supposed to be SMP so master/slave check +; makes no sense. +#ifdef CONFIG_ISA_ARCV2 ; Non-masters will be halted immediately, they might be kicked later ; by platform code right before passing control to the Linux kernel ; in bootm.c:boot_jump_linux(). @@ -25,6 +28,7 @@ ENTRY(_start) nop .Lmaster_proceed: +#endif /* Setup interrupt vector base that matches "__text_start" */ sr __ivt_start, [ARC_AUX_INTR_VEC_BASE] -- 2.7.4 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [uclibc-ng-devel] [PATCH] ldso/arc: fix debug prints
Hi Vineet, Vineet Gupta wrote, > Signed-off-by: Vineet Gupta > --- > ldso/ldso/arc/elfinterp.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/ldso/ldso/arc/elfinterp.c b/ldso/ldso/arc/elfinterp.c > index 2f0cf7f6635b..c164d5dae6bf 100644 > --- a/ldso/ldso/arc/elfinterp.c > +++ b/ldso/ldso/arc/elfinterp.c > @@ -179,8 +179,8 @@ _dl_do_reloc(struct elf_resolve *tpnt, struct > r_scope_elem *scope, > log_entry: > #if defined __SUPPORT_LD_DEBUG__ > if (_dl_debug_detail) > - _dl_dprintf(_dl_debug_file,"\tpatched: %lx ==> %lx @ %pl: > addend %x ", > - old_val, *reloc_addr, reloc_addr, > rpnt->r_addend); > + _dl_dprintf(_dl_debug_file,"\tpatched: %x ==> %x @ %x", > + old_val, *reloc_addr, reloc_addr); > #endif > > return 0; > @@ -215,7 +215,7 @@ _dl_do_lazy_reloc(struct elf_resolve *tpnt, struct > r_scope_elem *scope, > > #if defined __SUPPORT_LD_DEBUG__ > if (_dl_debug_reloc && _dl_debug_detail) > - _dl_dprintf(_dl_debug_file, "\tpatched: %lx ==> %lx @ %pl\n", > + _dl_dprintf(_dl_debug_file, "\tpatched: %x ==> %x @ %x\n", > old_val, *reloc_addr, reloc_addr); > #endif Applied and pushed, Waldemar ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [uclibc-ng-devel] [PATCH] ldso: exit if zalloc can't alloc memory
Hi Vineet, Vineet Gupta wrote, > _dl_zalloc callers don't check for allocaton failure. It kind of makes > sense since such early allocations are unlikely to fail, and even if > they do, ldso would segv anyways thus bringing the issue to attention. > > However there's a gcc nuance which led to this patch. > > It seems gcc at -O2 (for DODEBUG build), does additional coge gen > analysis for pointer dereference from erroneous paths and it "isolates" > such code paths with a intrinsic abort/trap etc. > > The ldso code fragment which was triggering this: > > | add_ldso(struct dyn_elf *rpnt) > |if (rpnt) > |... > |else > | rpnt = _dl_zalloc() > | > |rpnt->dyn = tpnt < potential NULL pointer deref > > ARC gcc currently generates an abort() call which doesn't exist in ldso, > causing link errors (with a newer vrsion of binutils). > > ARM gcc 6.2.1 behaves similarly, altough instead of abort, it generates > a trap inducing UDF instruction > > |367c:ebfffb79 bl 2468 <_dl_malloc> > |3680:e51b2068 ldr r2, [fp, #-104] ; 0xff98 > |3684:e350 cmp r0, #0 > |3688:0a06 beq 36a8 <_dl_add_elf_hash_table+0x280> > | ... > |36a8:e5862000 str r2, [r6] > |36ac:e7f000f0 udf # > > So add an explict dl_exit() in dl_zalloc error case to beat the > compiler. > > Note that this error propagagtion analysis stops if the function in > consideration (_dl_zalloc) is NOT inlined. Hence the reason it only > shows up for DODEBUG builds which builds ldso at -O2 which is more > aggressive about inlining. > > If this patch is not considered worth applying then the workaround > suggested by Claudiu is to to build ldso with > -fno-isolate-erroneous-paths-dereference > > Signed-off-by: Vineet Gupta Applied and pushed, Waldemar ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [uclibc-ng-devel] [PATCH] Same iteration variable used for inner and outer loop
Hi Cupertino, Cupertino Miranda wrote, > Inner loop was using same counter variable (i) as the outer loop, therefore > making outer loop terminate before it visited all of the ELF program segments. > Surrounding code in this inner loop clearly shows the intention that this loop > should not affect the outer one, therefore leading me to the conclusion that > this should be a bug an not expected code. > > This bug was detected due to some other bug in ARC binutils that kept setting > TEXTREL for any PIE application. > > Apart from the but, I have also moved the debug message inside of the TEXTREL > condition as mprotect is only really called if TELTREL is set. Thanks. Applied and pushed, Waldemar ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
static linking broken?
Hi Vineet, it seems static linking is totally broken for ARC and uClibc-ng: file root_nsim-arcv2_uclibc-ng_archs/bin/busybox root_nsim-arcv2_uclibc-ng_archs/bin/busybox: ELF 32-bit LSB executable, *unknown arch 0xc3* version 1 (SYSV), dynamically linked, interpreter *empty*, for GNU/Linux 4.8.0, stripped I am using arc-2016.09-release within OpenADK. Do you ever used static linking? I only test with nsim, but can't use any static binaries. best regards Waldemar ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: static linking broken?
On 04/11/2017 01:52 PM, Waldemar Brodkorb wrote: > Hi Vineet, > > it seems static linking is totally broken for ARC and uClibc-ng: > > file root_nsim-arcv2_uclibc-ng_archs/bin/busybox > root_nsim-arcv2_uclibc-ng_archs/bin/busybox: ELF 32-bit LSB > executable, *unknown arch 0xc3* version 1 (SYSV), dynamically > linked, interpreter *empty*, for GNU/Linux 4.8.0, stripped > > I am using arc-2016.09-release within OpenADK. > > Do you ever used static linking? > > I only test with nsim, but can't use any static binaries. > > best regards > Waldemar I do test static linked busybox and last I checked 2016.09 seemed ok ! (below is busybox built against prebuilt 2016.09 toolchain on github) $ file arc_initramfs_hs_1612-gnu-2016.09-BIG/bin/busybox_static ELF 32-bit LSB executable, *unknown arch 0xc3* version 1 (SYSV), statically linked, for GNU/Linux 4.8.0, not stripped Although I've seen this issue in different context - Linux kernel perf, Alexey u remember ! -Vineet ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
