Re: uclibc and smp
On Mon, Sep 22, 2008 at 12:34:53PM -0500, Rob Landley wrote: On Friday 05 September 2008 16:45:55 Joe Taylor wrote: I'm trying to obtain a rough measure of uclibc's maturity on SMP systems. I see some SMP hooks in the source code, but I cannot seem to find much information on uclibc-based projects running on SMP systems. SMP is really a kernel thing, not a userspace thing. (Userspace sees threading, but doesn't care if it's smp, UP scheduling, hyper-threading...) That's not entirely true, there are places in the libc where userspace cares, especially in terms of locking and mutex operations, and figuring out precisely how strong these need to be. NPTL does a number of optimizations in this case, for example. Beyond that, things like page placement, avoiding cacheline bouncing, CPU affinity, IRQ balancing, etc. are all very much userspace problems that the kernel can't do much about on its own, although these are not purely libc related issues. Regarding Joe's question, there are places where we can do some more optimizations on SMP, but there should be nothing today causing any instability with uClibc on SMP systems. If this is an area you are interested in, it would be nice to see some numbers comparing against glibc (although obviously this is going to be completely different for each platform, especially in relation to atomic ops), and any reports on whether you hit problems or not. I've not encountered any problems with uClibc on SH SMP, although we do need some atomic op changes based on auxvt hinting. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: [PATCH] posix_favise{64} error handling fixes [was Re: fadvise gclibc vs uclibc]
On Mon, Sep 15, 2008 at 01:55:56PM +0200, Carmelo AMOROSO wrote: Index: libc/sysdeps/linux/sh/bits/syscalls.h === --- libc/sysdeps/linux/sh/bits/syscalls.h (revision 23401) +++ libc/sysdeps/linux/sh/bits/syscalls.h (working copy) @@ -140,6 +140,151 @@ __syscall_return(type,__sc0); \ } +#define SYSCALL_INST_STR0trapa #0x10\n\t +#define SYSCALL_INST_STR1trapa #0x11\n\t +#define SYSCALL_INST_STR2trapa #0x12\n\t +#define SYSCALL_INST_STR3trapa #0x13\n\t +#define SYSCALL_INST_STR4trapa #0x14\n\t +#define SYSCALL_INST_STR5trapa #0x15\n\t +#define SYSCALL_INST_STR6trapa #0x16\n\t + This breaks SH-2/SH-2A, you should be using __SH_SYSCALL_TRAP_BASE here. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: [PATCH] posix_favise{64} error handling fixes [was Re: fadvise gclibc vs uclibc]
On Wed, Sep 24, 2008 at 01:22:51PM +0200, Carmelo AMOROSO wrote: Paul Mundt wrote: On Mon, Sep 15, 2008 at 01:55:56PM +0200, Carmelo AMOROSO wrote: Index: libc/sysdeps/linux/sh/bits/syscalls.h === --- libc/sysdeps/linux/sh/bits/syscalls.h (revision 23401) +++ libc/sysdeps/linux/sh/bits/syscalls.h (working copy) @@ -140,6 +140,151 @@ __syscall_return(type,__sc0); \ } +#define SYSCALL_INST_STR0 trapa #0x10\n\t +#define SYSCALL_INST_STR1 trapa #0x11\n\t +#define SYSCALL_INST_STR2 trapa #0x12\n\t +#define SYSCALL_INST_STR3 trapa #0x13\n\t +#define SYSCALL_INST_STR4 trapa #0x14\n\t +#define SYSCALL_INST_STR5 trapa #0x15\n\t +#define SYSCALL_INST_STR6 trapa #0x16\n\t + This breaks SH-2/SH-2A, you should be using __SH_SYSCALL_TRAP_BASE here. Hi Paul, it was taken from a sysdep.h in nptl path, that probably doesn't care of SH-2[A]. I'll fit it immediately. Indeed, we've not started looking at threading on nommu yet, but it's likely something that will surface sooner or later. Thanks for fixing it up, I've checked in a fix for the vfork implementation also, which had the same problem. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: [PATCH] sh: fix SYSCALL_INST_STR macros for SH-2[A] arch.
On Wed, Sep 24, 2008 at 03:44:34PM +0200, Carmelo AMOROSO wrote: Hi Paul, please find attached a patch to make SYSCALL_INST_STR macros working on SH2 too. I've built trunk for sh4 and objdumped some object using INLINE_SYSCALL, and it looks fine. Let me know, so I can commit. Carmelo Index: libc/sysdeps/linux/sh/bits/syscalls.h === --- libc/sysdeps/linux/sh/bits/syscalls.h (revision 23456) +++ libc/sysdeps/linux/sh/bits/syscalls.h (working copy) @@ -140,14 +140,19 @@ __syscall_return(type,__sc0); \ } -#define SYSCALL_INST_STR0trapa #0x10\n\t -#define SYSCALL_INST_STR1trapa #0x11\n\t -#define SYSCALL_INST_STR2trapa #0x12\n\t -#define SYSCALL_INST_STR3trapa #0x13\n\t -#define SYSCALL_INST_STR4trapa #0x14\n\t -#define SYSCALL_INST_STR5trapa #0x15\n\t -#define SYSCALL_INST_STR6trapa #0x16\n\t +/* Two level macros for expansion and stringification */ +#define xstr(s) str(s) +#define str(s) #s uClibc has no equivalent of __stringify()? This should probably be in a generic header somewhere. +#define SYSCALL_INST_STR(x) trapa #xstr(__SH_SYSCALL_TRAP_BASE + x)\n\t +#define SYSCALL_INST_STR0SYSCALL_INST_STR(0) +#define SYSCALL_INST_STR1SYSCALL_INST_STR(1) +#define SYSCALL_INST_STR2SYSCALL_INST_STR(2) +#define SYSCALL_INST_STR3SYSCALL_INST_STR(3) +#define SYSCALL_INST_STR4SYSCALL_INST_STR(4) +#define SYSCALL_INST_STR5SYSCALL_INST_STR(5) +#define SYSCALL_INST_STR6SYSCALL_INST_STR(6) + # ifdef NEED_SYSCALL_INST_PAD # define SYSCALL_INST_PAD \ or r0,r0; or r0,r0; or r0,r0; or r0,r0; or r0,r0 The rest obviously looks fine. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: wrong sources
[ Adding uclibc to CC, in the future please use this instead of blindly
CCing everyone ]
On Tue, Sep 16, 2008 at 07:52:40PM +0200, Dmytro Gorbunov wrote:
Dear sir,
Please be informed that following code for project uClibc in file
http://freshmeat.net/ redir/ uclibc/ 20616/ url_bz2/
uClibc-0.9.28.1.tar.bz2/ uClibc-0.9.29/ libc/ stdio/open_memstream. is
wrong because memset function shouldn't take zero in 3rd parameter.
code
memset(buf + COOKIE-eof, leastlen - COOKIE-eof, 0);
/code
Thanks for the report. This does seem to be buggy at first glance. I'll
check in the attached patch unless anyone yells.
---
Index: libc/stdio/open_memstream.c
===
--- libc/stdio/open_memstream.c (revision 23438)
+++ libc/stdio/open_memstream.c (working copy)
@@ -107,7 +107,7 @@
*pos = COOKIE-pos = --leastlen;
if (leastlen COOKIE-eof) {
- memset(COOKIE-buf + COOKIE-eof, leastlen - COOKIE-eof, 0);
+ memset(COOKIE-buf + COOKIE-eof, 0, leastlen - COOKIE-eof);
*COOKIE-sizeloc = COOKIE-eof;
}
___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: wrong sources
On Sat, Sep 20, 2008 at 11:39:29PM -0400, Frysinger, Michael wrote:
Index: libc/stdio/open_memstream.c
===
--- libc/stdio/open_memstream.c (revision 23438)
+++ libc/stdio/open_memstream.c (working copy)
@@ -107,7 +107,7 @@
*pos = COOKIE-pos = --leastlen;
if (leastlen COOKIE-eof) {
- memset(COOKIE-buf + COOKIE-eof, leastlen - COOKIE-eof, 0);
+ memset(COOKIE-buf + COOKIE-eof, 0, leastlen - COOKIE-eof);
*COOKIE-sizeloc = COOKIE-eof;
}
there's actually two memset()'s iirc
So there is, I missed it as the original report only referred to a
specific instance. Anyways, here's the updated patch:
Index: libc/stdio/open_memstream.c
===
--- libc/stdio/open_memstream.c (revision 23438)
+++ libc/stdio/open_memstream.c (working copy)
@@ -97,7 +97,7 @@
if (buf) {
*COOKIE-bufloc = COOKIE-buf = buf;
COOKIE-len = leastlen;
- memset(buf + COOKIE-eof, leastlen - COOKIE-eof, 0);
/* 0-fill */
+ memset(buf + COOKIE-eof, 0, leastlen - COOKIE-eof);
/* 0-fill */
} else {
/* TODO: check glibc errno setting... */
return -1;
@@ -107,7 +107,7 @@
*pos = COOKIE-pos = --leastlen;
if (leastlen COOKIE-eof) {
- memset(COOKIE-buf + COOKIE-eof, leastlen - COOKIE-eof, 0);
+ memset(COOKIE-buf + COOKIE-eof, 0, leastlen - COOKIE-eof);
*COOKIE-sizeloc = COOKIE-eof;
}
___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: [PATCH] sh: fix __HAVE_SHARED__ condition in crti.S.
On Tue, Sep 02, 2008 at 02:09:20PM +0200, Carmelo AMOROSO wrote: I did not success to create a test that could fail. application ctor/dtor defined by gcc attribute ((__contructor__)) on ((__destructor__)) are correctly invoked. Indeed, if I put the ctor/dtor in a separate object file and I build it as a PIC object, then the compiler will create the proper _GLOBAL_OFFSET_TABLE_ entry and will produce the proper code to load and use r12. Yes, glibc _init function does it, but I'm thinking that it is useless. I cannot see a scenario in which this may fail. Are we sure we need this code at all? or we simply have taken the code as is from glibc in the past ? I expect it is just something that was blindly copied from glibc. I wasn't the one that copied it in to uclibc originally, but I would wager it's a sanity measure to work around old compilers. The GCC ident references 3.3.2, I don't have anything that old sitting around any more, but it might be worth testing out with something before that to see if the proper entry is generated without the init/fini help before deciding whether to axe the code completely or not. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: [PATCH] sh: fix __HAVE_SHARED__ condition in crti.S.
On Thu, Aug 28, 2008 at 07:58:15AM +0200, Carmelo AMOROSO wrote: Paul Mundt wrote: On Tue, Aug 26, 2008 at 03:53:18PM +0200, Carmelo AMOROSO wrote: Takashi Yoshii wrote: For SH, init/fini function prologue is defined in libc/sysdeps/linux/sh/crti.S as follows. | (frame entry) |#ifndef __HAVE_SHARED__ | (GOT pointer initialization) |#endif I think this should be ifdef, but ifndef. Or, are there any reason that GOT should be used (only)in NON-shared case ? Well, this change has been committed by lethal at http://www.uclibc.org/cgi-bin/viewcvs.cgi/trunk/uClibc/libc/sysdeps/linux/sh/crti.S?rev=16426view=diffr1=16426r2=16425p1=trunk/uClibc/libc/sysdeps/linux/sh/crti.Sp2=/trunk/uClibc/libc/sysdeps/linux/sh/crti.S so, unless there something I'm not understanding too, I suppose it was a typo by Paul (aka lethal). Paul, my you give some lights on this change ? I had to think about this briefly. It was part of the SH-2 work done by Mark Shinwell (added to Cc). The disabling of GOT related code in the non-shared case was intentional, but I don't immediately recall what the rationale was. yes, but as Yoshii spotted, the code now seems doing just the opposite. Good point, it seems I'm unable to read in that case. :-) Inverting it seems to be the reasonable thing to do. I'll give it a test and check in Yoshii-san's patch if nothing breaks. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: [PATCH] sh: fix __HAVE_SHARED__ condition in crti.S.
On Tue, Aug 26, 2008 at 03:53:18PM +0200, Carmelo AMOROSO wrote: Takashi Yoshii wrote: For SH, init/fini function prologue is defined in libc/sysdeps/linux/sh/crti.S as follows. | (frame entry) |#ifndef __HAVE_SHARED__ | (GOT pointer initialization) |#endif I think this should be ifdef, but ifndef. Or, are there any reason that GOT should be used (only)in NON-shared case ? Well, this change has been committed by lethal at http://www.uclibc.org/cgi-bin/viewcvs.cgi/trunk/uClibc/libc/sysdeps/linux/sh/crti.S?rev=16426view=diffr1=16426r2=16425p1=trunk/uClibc/libc/sysdeps/linux/sh/crti.Sp2=/trunk/uClibc/libc/sysdeps/linux/sh/crti.S so, unless there something I'm not understanding too, I suppose it was a typo by Paul (aka lethal). Paul, my you give some lights on this change ? I had to think about this briefly. It was part of the SH-2 work done by Mark Shinwell (added to Cc). The disabling of GOT related code in the non-shared case was intentional, but I don't immediately recall what the rationale was. Original thread here: http://www.uclibc.org/lists/uclibc/2006-October/016617.html I expect that it's related to the ABI, in that we also don't have the GOT references in the FDPIC case, so it should likely be conditionalized for the targets that actually emit _GLOBAL_OFFSET_TABLE_, rather than depending on __HAVE_SHARED__. While I hit this on FDPIC, I would wager that Mark hit this on shared FLAT (which we don't have support in-tree for anyways) on his internal libc. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: [PATCH] sh: Fix args for __uClibc_main() in crt1.S
On Fri, Aug 08, 2008 at 10:04:27AM +0900, Takashi Yoshii wrote: This still requires the kernel zeroing the r4 value before handing control over as per your FLAT_PLAT_INIT() patch, correct? Yes. I think kernel should set(clear) r4 for static object(ELF and FLT). For shared one(currently ELF), dl-start.h(uClibc)/dl-machine.h(glibc) set r4. # Perhaps the real answer depends on what FLAT's ABI says. But, so far, yes. Ok, I'll roll that in to my -rc3 updates then, thanks for the confirmation. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: [PATCH] sh: Fix args for __uClibc_main() in crt1.S
On Thu, Aug 07, 2008 at 08:30:37AM +0200, Carmelo AMOROSO wrote: please find attached another patch to completely fix the sh4 startup sequence (in addition to the patch of Yoshii). As you can see from the log below, DSO's destructor now is called. Paul, does it sound good for you ? [snip] Fix ldso startup sequence by passing via r4 the rtls finalizer _dl_fini to the user application. This will be the 6^ arg of __uClibc_main and will be registered with 'atexit'. In this way the dynamic linker will be able to call destructors defined within the loaded DSO. Signed-off-by: Carmelo Amoroso [EMAIL PROTECTED] Looks good to me, yes. Thanks for debugging this down! Acked-by: Paul Mundt [EMAIL PROTECTED] On Thu, Aug 07, 2008 at 06:00:22PM +0900, Takashi Yoshii wrote: Hi, please find attached another patch to completely fix the sh4 startup sequence (in addition to the patch of Yoshii). Tested. It works fine here. Great. # Sorry for my slow writing(code/mail) made useless traffic. /yoshii This still requires the kernel zeroing the r4 value before handing control over as per your FLAT_PLAT_INIT() patch, correct? ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: [PATCH] sh4 supports new {s,g]rlimit syscall
On Tue, Jul 08, 2008 at 10:26:11AM +0200, Carmelo AMOROSO wrote: Hi Paul, are you ok with changing default behaviour on sh4 regarding RLIMIT wrapper. The change in the attached patch was required to fix LTP/setrlimit02 test case. Looks fine to me. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: svn commit: trunk/uClibc/ldso/ldso/sh
On Sat, Jan 12, 2008 at 07:06:02PM +0100, Carmelo Amoroso wrote: Mike Frysinger wrote: On Saturday 12 January 2008, [EMAIL PROTECTED] wrote: Author: carmelo Date: 2008-01-12 00:20:18 -0800 (Sat, 12 Jan 2008) New Revision: 20848 Log: Make sh4 build works again adding a temporary work-around iby redefining __always_inline to inline until gcc 4.x.x will get fixed. Modified: trunk/uClibc/ldso/ldso/sh/dl-syscalls.h +#warning !!! __always_inline redefined waiting for the fixed gcc +#ifdef __always_inline +#undef __always_inline +#define __always_inline inline +#endif shouldnt you leverage __GNUC_PREREQ(4, 0) ? and add information about what version of gcc is actually broken ? -mike Hi Mike, done. I'm assuming the problem is with gcc 4.1 and later. If your new compiler is sane enough to define __GNUC_STM_RELEASE__ as was discussed before, it might be worth conditionalizing on that also. We already do that in the kernel for some other cases.. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: Prepending underscores to symbol names in dlsym() (commit 20613)
On Tue, Jan 08, 2008 at 09:54:22AM +, Will Newton wrote: On Jan 7, 2008 4:30 PM, Carmelo AMOROSO [EMAIL PROTECTED] wrote: Will Newton wrote: Hi Bernd, (I hope I got the right email address here) I noticed commit 20613 prepends an underscore to the symbol name passed to dlsym() if __UCLIBC_NO_UNDERSCORE__ is not defined. I was wondering if you could explain the rationale behind this change? It seems to me the it's just the opposite Hmm, no, I think what I said is correct. If no underscores is NOT defined then we prepend the underscore. You both appear to be in agreement on the result. The patch does precisely what is described: +++ trunk/uClibc/ldso/include/dl-defs.h 2007-12-03 22:46:53 UTC (rev 20613) @@ -175,4 +175,10 @@ # define DL_MALLOC_ALIGN (__WORDSIZE / 8) #endif +#ifdef __UCLIBC_NO_UNDERSCORES__ +#define __C_SYMBOL_PREFIX__ +#else +#define __C_SYMBOL_PREFIX__ _ +#endif + #endif /* _LD_DEFS_H */ Additionally, this sort of backwards logic is precisely why having inverted ifdef logic is absolute brain-damage. #ifndef __UCLIBC_UNDERSCORES__ is infinitely more readable, even though an #ifdef __UCLIBC_HELP_MY_TOOLCHAIN_SUCKS__ would be more intuitive at first glance (and more fitting, for those insisting on using -elf toolchains). It's like SYMBOL_PREFIX() hell all over again.. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: [PATCH] Always inline system calls
On Mon, Dec 03, 2007 at 10:33:39PM +0100, Carmelo Amoroso wrote:
Carmelo Amoroso wrote:
while doing some test for SH4 to measure size increase for 'always inline'
changes,
doscovered suddenly that gcc-4.1.1 (cross sh4) fails with the following error:
../ldso/ldso/dl-elf.c: In function '_dl_dprintf':
../ldso/ldso/dl-elf.c:858: error: unable to find a register to spill in class
'R0_REGS'
../ldso/ldso/dl-elf.c:858: error: this is the insn:
(insn 916 917 24 1 (set (reg/f:SI 1 r1 [219])
(mem/u/c:SI (plus:SI (reg:SI 12 r12)
(reg/f:SI 1 r1 [220])) [0 S4 A32])) 172 {movsi_ie} (nil)
(expr_list:REG_DEAD (reg/f:SI 1 r1 [220])
(expr_list:REG_EQUIV (symbol_ref:SI (_dl_pagesize) var_decl
0x313a720 _dl_pagesize)
(nil
either running with -Os or -O0.
I'll test tomorrow with gcc-4.2.1 to see if it makes difference,
otherwise I suspect we should go back on my proposal in using always inline
only for arch strictly requiring it.
We've noticed this with some versions in buildroot also, so it seems to
be a more common issue:
CC ldso/ldso/ldso.oS
In file included from
./libpthread/linuxthreads.old/sysdeps/sh/tls.h:23,
from ./include/bits/uClibc_errno.h:35,
from ./include/errno.h:62,
from ./include/bits/syscalls.h:16,
from ./include/sys/syscall.h:34,
from ./ldso/ldso/sh/dl-syscalls.h:3,
from ./ldso/include/dl-syscall.h:12,
from ./ldso/include/ldso.h:36,
from ldso/ldso/ldso.c:33:
./libpthread/linuxthreads.old/sysdeps/sh/pt-machine.h:36: warning: C99
inline functions are not supported; using GNU89
./libpthread/linuxthreads.old/sysdeps/sh/pt-machine.h:36: warning: to
disable this warning use -fgnu89-inline or the gnu_inline function attribute
ldso/ldso/dl-elf.c: In function '_dl_dprintf':
ldso/ldso/dl-elf.c:803: error: unable to find a register to spill in
class 'R0_REGS'
ldso/ldso/dl-elf.c:803: error: this is the insn:
(insn 884 885 23 3 (set (reg/f:SI 1 r1 [221])
(mem/u/c:SI (plus:SI (reg:SI 12 r12)
(reg/f:SI 1 r1 [222])) [0 S4 A32])) 171 {movsi_ie} (nil)
(expr_list:REG_DEAD (reg/f:SI 1 r1 [222])
(expr_list:REG_EQUIV (symbol_ref:SI (_dl_pagesize)
var_decl 0x402d7660 _dl_pagesize)
(nil
ldso/ldso/dl-elf.c:803: confused by earlier errors, bailing out
make[1]: *** [ldso/ldso/ldso.oS] Error 1
So inlining itself may not really be a problem, but it might be worthwhile
hunting down the code that generates the immediate load and seeing if that can
be forced in to a memory access instead, so we avoid the R0 encoding dependence.
These are all in relation to _dl_pagesize at least.
___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: [PATCH]: ARM SHMLBA
Hi Carmelo, On Sat, Dec 01, 2007 at 08:52:45AM +0100, Carmelo Amoroso wrote: Paul Mundt wrote: On Tue, Nov 20, 2007 at 08:30:04AM +0100, Carmelo AMOROSO wrote: Same issue as SH4 (solved in the past). Solved is relative. What's there now works, but it's a pretty idiotic hack, and is certainly not solved for the multiple page size cases. The current implementation is certainly sub-optimal for 8kB (SH-X2 and later) and 64kB PAGE_SIZE (SH-4, SH-5, SH-X2 and later, etc.), and we really do need to take the L1 shape in to account for handling this properly. So it does work, but it will spread things out far more than they need to be. Most of the information needed for fixing this properly can be extracted from the ELF auxvt, though I never quite got around to finishing up the code for that. do you mean passing the shm_alignment value from kernel to ld.so through the auxvt ? if so, I could try to provide a patch for the kernel and then update th ld.so to take care of this. What I meant was using the same math for calculating shm_align_mask in userspace based on the L1 D-cache shape. The auxvt has pre-supported cache shape entries that we can use for populating with the cache info and support in a semi-portably fashion on the userspace side. If I recall correctly, it was Alpha that added these initially. So basically I would like to see AT_Lx_CACHESHAPE used for working this out. The biggest issue is that we need a bit of leg-work in uClibc for parsing the auxvt in the first place. I had some code hacked together for that, but never got around to polishing it off. We need this as a base step for hooking up the vdso entry as well -- which I suspect might be of interest to you guys especially since you can do away with the context switch overhead on your sys_cacheflush ;-) ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: [PATCH]: ARM SHMLBA
On Tue, Nov 20, 2007 at 08:30:04AM +0100, Carmelo AMOROSO wrote: Khem Raj wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi ARM SHMLBA = (4 * PAGE_SIZE). Currently in uclibc arm used shm.h from common directory where SHMLBA = __getpagesize() This patch fixes the issue. OK for trunk ? Same issue as SH4 (solved in the past). Solved is relative. What's there now works, but it's a pretty idiotic hack, and is certainly not solved for the multiple page size cases. The current implementation is certainly sub-optimal for 8kB (SH-X2 and later) and 64kB PAGE_SIZE (SH-4, SH-5, SH-X2 and later, etc.), and we really do need to take the L1 shape in to account for handling this properly. So it does work, but it will spread things out far more than they need to be. Most of the information needed for fixing this properly can be extracted from the ELF auxvt, though I never quite got around to finishing up the code for that. The easy solution is of course just growing SHMLBA to the point where there isn't a problem anymore, and I expect this will be the continued approach favoured by vendors until a proper fix is put in place ;-) ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: [Buildroot] Buildroot Compile Errors for SH4
On Tue, Apr 10, 2007 at 11:43:07PM +0200, Carmelo Amoroso wrote: Paul Mundt wrote: This is the syscall() definition in the __USE_MISC case, and it's certainly not limited to SH. There are hardly any users that implement syscall() using varargs, so this will break other places as well. Hi Paul, it's very strange, but I'm able to build the snapshot of trunk for sh4 without problems (with my last patch to fix procfs.h committed by Mike). I'm using cross gcc4.1.1/binutils 2.17.50.0.5 on both MacOSX 10.4 (darvin 8.9.1) and RH Linux. I've checked that __USE_MISC is defined for me. My guess would be that this is something that was introduced with gcc 4.2, I've not hit this with 4.1.1 in the past either.. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: [Buildroot] Buildroot Compile Errors for SH4
On Tue, Apr 10, 2007 at 09:58:02PM +0200, Bernhard Fischer wrote:
On Tue, Apr 10, 2007 at 03:43:32PM -0400, Bill Traynor wrote:
On 4/10/07, Bill Traynor [EMAIL PROTECTED] wrote:
CC libc/sysdeps/linux/sh/syscall.os
libc/sysdeps/linux/sh/syscall.c:11: error: conflicting types for 'syscall'
./include/unistd.h:1016: error: previous declaration of 'syscall' was here
So the offending code is:
syscall.c
long syscall(long sysnum,
long arg1, long arg2, long arg3,
long arg4, long arg5, long arg6)
{
register long __sc3 __asm__ (r3) = sysnum;
register long __sc4 __asm__ (r4) = (long) arg1;
register long __sc5 __asm__ (r5) = (long) arg2;
register long __sc6 __asm__ (r6) = (long) arg3;
register long __sc7 __asm__ (r7) = (long) arg4;
register long __sc0 __asm__ (r0) = (long) arg5;
register long __sc1 __asm__ (r1) = (long) arg6;
__asm__ __volatile__ (
trapa %1
: =z (__sc0) \
: i (__SH_SYSCALL_TRAP_BASE + 6),
0 (__sc0), r (__sc4), r (__sc5), r (__sc6), r (__sc7), \
r (__sc3), r (__sc1) \
: memory );
__syscall_return(long,__sc0);
}
and unistd.h:
extern long int syscall (long int __sysno, ...) __THROW;
The question now is how to fix this for SH.
This is the syscall() definition in the __USE_MISC case, and it's
certainly not limited to SH. There are hardly any users that implement
syscall() using varargs, so this will break other places as well.
We could convert syscall() to use varargs, though we'd have to take the
length of the arglist to add to __SH_SYSCALL_TRAP_BASE, though as
_syscall6() is the worst case, so perhaps that's fine in the general
case.
I suppose the question is why some are using varargs and others aren't. I
don't mind changing it if there's a consensus. In any event, this will
hit pretty much all of the other architectures, too..
___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc
