Re: [PATCH v3] xtensa: ldso: coalesce dl_mprotect address ranges

[Bernhard Reutner-Fischer]

On 10 January 2015 at 02:42, Max Filippov jcmvb...@gmail.com wrote:
 This noticeably lowers the number of mprotect calls at program startup,
 e.g. for busybox: 7 calls vs 1835 calls.

 Signed-off-by: Max Filippov jcmvb...@gmail.com
 ---
 Changes v2-v3:
 - coalesce address ranges that overlap in any way, not only at the end of
   the existing range.

 Changes v1-v2:
 - initialize prev_got_start and prev_got_end in INIT_GOT as well.

  ldso/ldso/xtensa/dl-startup.h | 20 +++-
  ldso/ldso/xtensa/dl-sysdep.h  | 24 +++-
  2 files changed, 42 insertions(+), 2 deletions(-)

 diff --git a/ldso/ldso/xtensa/dl-startup.h b/ldso/ldso/xtensa/dl-startup.h
 index b135a4c..0c28d5e 100644
 --- a/ldso/ldso/xtensa/dl-startup.h
 +++ b/ldso/ldso/xtensa/dl-startup.h
 @@ -83,6 +83,7 @@ do { \
 unsigned long l_addr = tpnt-loadaddr; \
 Elf32_Word relative_count; \
 unsigned long rel_addr; \
 +   Elf32_Addr prev_got_start = 0, prev_got_end = 0; \

The whole file could need a touch-up WRT ElfW macros, see include/link.h

Applied, thanks!
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [PATCH] add argument check in setenv()

[Bernhard Reutner-Fischer]

On 4 November 2014 at 12:26, Xishi Qiu qiuxi...@huawei.com wrote:
 setenv() in glibc/eglibc will check the argument, like this,

Applied. Thanks!
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [PATCH] add argument check in mknod

[Bernhard Reutner-Fischer]

On 11 November 2014 at 08:59, wangyufen wangyu...@huawei.com wrote:
 mknod() in glibc/eglibc will check the argument, like this,

Applied, thanks!
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [PATCH] ARC: Add GNU glob to ARC defconfigs

[Bernhard Reutner-Fischer]

On February 5, 2015 8:20:57 PM GMT+01:00, Rich Felker dal...@libc.org wrote:
On Wed, Feb 04, 2015 at 03:58:41PM +, Anton Kolesov wrote:
 Now I've looked into more details of error cause and what happens is
 that those fields (gl_opendir, gl_readdir, gl_closedir, gl_stat) in
 glob_t in uclibc/include/glob.h are surrounded by #ifdef
 __UCLIBC_HAS_GNU_GLOB__. Make might be built without GNU glob on
 target system because it contains its own copy in source tree and
 uses it when it detects that target system doesn’t have GNU glob.
 However the way it checks for GNU glob is not compatible with
 uClibc, because make/configure checks for 
 _GNU_GLOB_INTERFACE_VERSION == 1 as an indicator that GNU glob is
 present, but uclibc/gnu-versions.h defines
 _GNU_GLOB_INTERFACE_VERSION as 1 regardless of whether GNU glob is
 present in configuration. Thus make/configure decides that GNU glob
 is present when it is not, which causes further compilation error.

I think the definition of _GNU_GLOB_INTERFACE_VERSION just needs to be
moved inside the #ifdef __UCLIBC_HAS_GNU_GLOB__. uclibc should not be
reporting that it has GNU glob when it was built without it.

Right.


___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: 0.9.33 branch development / release process

[Bernhard Reutner-Fischer]

On February 5, 2015 6:57:53 PM GMT+01:00, Andy Voltz andy.vo...@timesys.com 
wrote:
What is the current release process for uClibc?

I'm looking to bump our build system to a newer uClibc version, but
there
are no new release tags since 0.9.33.2. It seems like the 0.9.33 branch
could be treated as version 0.9.33.3, but there was never a tag, and

We will have a 0.9.33.3 off the 0.9.33 branch.

now
master is 0.9.33.4-git.

Is the process to create a branch for the version once it's development
is
complete? I'd rather not use 0.9.33 branch if it is some abandoned /
unstable effort, but at the same time the master branch seems active
enough
to not treat as a stable release.

I consider master pretty stable and intend to have a new stable release of a 
0.9.34 off master hopefully this month.

HTH,

Thank you for any clarification you can provide on this.

Regards,

-Andy
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc


___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: executable RPATH question

[Bernhard Reutner-Fischer]

On February 6, 2015 8:23:27 AM GMT+01:00, Waldemar Brodkorb w...@openadk.org 
wrote:
Hi Steve,
Steve Ellcey  wrote,

 While building uclibc for MIPS I ran into the issue of whether or not
 the dynamic linker should use an executables rpath when searching for
 its libraries.  Apparently the glibc dynamic linker does this, but
the
 uclibc one does not and back when this was discussed in 2011 the
decision
 was made not to change the uclibc behaviour because the ELF spec does
not
 say that the linker should do this.
 
 At the risk of of reopening a closed issue I was wondering if we
could
 consider putting the code to do this in under an ifdef or a config
option
 so that those of us who want it could have it without having to
maintain
 a local patch for it.  If not, I will just maintain my local patch.
 
 Original discussion:
 
 http://lists.uclibc.org/pipermail/uclibc/2011-September/045757.html

Do you have a patch which applies to master?
Including an option...

I still think this is wrong. Just set the RUNPATH of the first lib correctly 
(and fix glibc):

http://www.sco.com/developers/gabi/latest/ch5.dynamic.html#shobj_dependencies

The set of directories specified by a given DT_RUNPATH entry is used to find 
only the immediate dependencies of the executable or shared object containing 
the DT_RUNPATH entry. That is, it is used only for those dependencies contained 
in the DT_NEEDED entries of the dynamic structure containing the 
DT_RUNPATHentry, itself. One object's DT_RUNPATHentry does not affect the 
search for any other object's dependencies.


___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [PATCH v2] uclibc:fix basename modify the input path

[Bernhard Reutner-Fischer]

On 24 September 2014 at 04:47, Wangyufen wangyu...@huawei.com wrote:
 From: Wang Yufen wangyu...@huawei.com

 I tested basename(path), path is ///, the basename(path) returned /,
 but the input path also be modified to /. It because in basename impl,
 last[1] = 0; modified the input path, I think that isn't correct.

This is perfectly legal.
See http://pubs.opengroup.org/onlinepubs/9699919799/functions/basename.html

   text   databssdechex filename
165  0  0165 a5 libc/string/__xpg_basename.os
113  0  0113 71 libc/string/__xpg_basename.os.orig

Since the current behaviour is in accordance to the standard and your version
is way bigger i prefer to keep it as is.

Thanks anyway!
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: tests are failing

[Bernhard Reutner-Fischer]

On 20 December 2014 at 12:39, Bernhard Reutner-Fischer
rep.dot@gmail.com wrote:

 On 20 Dec 2014 04:53, Waldemar Brodkorb w...@openadk.org wrote:

 Hi Bernhard,

 after your commit

 http://git.uclibc.org/uClibc/commit/?id=067637375658047d70c296606ae17ef0bc86499d
 tst-cancel7x and others are failing.
 You changed the getopt handling, but not how the tests are called.

 http://git.uclibc.org/uClibc/tree/test/nptl/tst-cancel7.c?id=067637375658047d70c296606ae17ef0bc86499d#n35

Should be fixed on master.

Thanks for the report!
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [PATCH] ARC: Add GNU glob to ARC defconfigs

[Bernhard Reutner-Fischer]

On February 18, 2015 7:01:23 AM GMT+01:00, Vineet Gupta 
vineet.gup...@synopsys.com wrote:
On Saturday 14 February 2015 01:32 AM, Bernhard Reutner-Fischer wrote:
 I'm not really a libc developer so I would refrain from deciding
what
 is right and what is wrong with those defines, I just need make
to
 run uClibc testsuite and Vineet greenlighted for me enabling gnu
glob
 in default config for ARC.
 So we will just enable the GNU glob for ARC as a quick measure and I
already planned to look into removing our cheat after the release, thus
we can easily disable GNU glob for the defconfig afterwards.
 
 Thanks,

Hi Bernhard,

Can u please do that as a standalone commit or perhaps squash it with
3/8 in my
other series.

I committed it as separate patch yesterday evening.
See?

Thanks,


___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [PATCH 0/8] ARC updates to uClibc

[Bernhard Reutner-Fischer]

On February 18, 2015 6:51:17 AM GMT+01:00, Vineet Gupta 
vineet.gup...@synopsys.com wrote:
On Monday 16 February 2015 08:34 PM, Bernhard Reutner-Fischer wrote:
 While it at I also did some arch specific adjustment in sigaction
path
 - inlining the rt_sigaction syscall stub detour to reduce branch
return
 stack mispredicts etc - which is what 6/8 does !
 This sounds suspicious.
 IIRC we already had that argument, last time around _dl_do_reloc and
_dl_do_lazy_reloc.
 Could it be that your port has a bug here ( missed optimisation )
around ifunc handling? Sounds like back then on ARM
https://gcc.gnu.org/PR40887#c6
 
 What am I missing?


I don't think my use-case is close to the ARM issue u pointed to above
as there is
no ifunc or function pointer involved.

I was more thinking about the relic functors.
Does GCC 5 produce identical code for ARC master way to explicit function calls 
compared to using a function pointer like suggested and used in all other ports?
If not then I'd consider this a bug.


With orig code, we get 2 function calls on ARC:

b504 __libc_sigaction:
b504:  push_s blink
b506:  sub_s  sp,sp,12
b508:  bl.d   36b20 __st_r13_to_r15
...

b540:  bl.d   b750 __syscall_rt_sigaction   --- DIRECT CALL
b544:  mov_s  r3,8
b546:  add_s  sp,sp,20
b548:  mov_s  r12,12
b54a:  b  36b88 __ld_r13_to_r15_ret
b54e:  nop_s

b750 __syscall_rt_sigaction:
b750:  movr8,134
b754:  swi SYSCALL TRAP INTO KERNEL
b758:  cmpr0,0xfc00
b75c:  bls_s  b76a
b75e:  st.a   blink,[sp,-4]
b762:  bl b550 __syscall_error
b766:  ld.ab  blink,[sp,4]
b76a:  j_s[blink]

The small function call is not necessarily good micro-architecturally
when
returning due to limited number of call return stack entries. That cost
is
amortized if function is largish.

I do understand that these small syscall wrappers are a common uClibc
design
pattern and exist all over the place but given that this was all arch
code I tool
the liberty of removing the one hop and the code now looks as below:

b4d8 __libc_sigaction:
b4d8:  st.a   gp,[sp,-4]
b4dc:  sub_s  sp,sp,20
b4de:  addgp,pcl,0x00065284
b4e6:  breq_s r1,0,b516
b4e8:  ld_s   r3,[r1,4]
...
b516:  movr8,134
b51a:  mov_s  r3,8
b51c:  swi
b520:  cmpr0,0xfc00
b524:  bls_s  b532
b526:  st.a   blink,[sp,-4]
b52a:  bl b53c __syscall_error
b52e:  ld.ab  blink,[sp,4]
b532:  ld.a   gp,[sp,20]
b536:  j_s.d  [blink]
b538:  add_s  sp,sp,4
b53a:  nop_s

I would have assumed / hoped that GCC 5 should generate this 2nd variant for 
extern inline __syscall_rt_sigaction.

Doesn't it do that?

TIA

___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [PATCH 0/2] speedup getline/getdelim/fgets_unlocked

[Bernhard Reutner-Fischer]

On November 19, 2014 11:38:38 PM GMT+01:00, Ed W li...@wildgooses.com wrote:
On 19/11/2014 15:52, Bernhard Reutner-Fischer wrote:
 On 18 June 2012 17:45, Ed W li...@wildgooses.com wrote:

 I remain *interested*, but I'm tied up with a bunch of deadlines and
not a
 proper build environment to test under... For reference it was
killing me
 with regards to modprobe, but I suspect it would have an impact on
other
 shell tools such as sed/awk, so it's definitely worth pushing
(sorry, just
 realised this is the uclibc list, the effect originally hit me
upstream in
 busybox)

 Can someone else ack that the changes have benefit?
 Anyone interested? :)


Ooops, that dropped off my todo!  I'm travelling until at least late 
next week.  Will get a look when I get back home

Great, looking forward to hear from you in this regard! :)


___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [PATCH] Add eventfd_read() and eventfd_write()

[Bernhard Reutner-Fischer]

On January 31, 2015 10:38:14 AM GMT+01:00, Bernd Kuhls 
bernd.ku...@t-online.de wrote:
Hi,

uClibc lacks eventfd_read() and eventfd_write(),

Applied.
Thanks for the reminder!
Cheers,

___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [PATCH] Replace strstr() implementations with faster two-way version

[Bernhard Reutner-Fischer]

On January 4, 2015 8:07:45 PM GMT+01:00, Jody Bruchon j...@jodybruchon.com 
wrote:
Whoops, it seems I typed Stephen's initials wrong in that patch text. 
s/SJVDB/SRVDB/g and apologies for that.

I have queued to look at it in detail after the release.
Will get back to you then.
Thanks for your patience!


___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [PATCH 0/4] uClibc port to ARCv2 ISA

[Bernhard Reutner-Fischer]

On February 18, 2015 1:11:03 PM GMT+01:00, Vineet Gupta 
vineet.gup...@synopsys.com wrote:
Hi,

Please find set of patches to support ARCv2 ISA basis of new HS family
of cores
from Synopsys.

http://www.synopsys.com/dw/ipdir.php?ds=arc-hs38-processorelq_mid=5732elq_cid=458802
http://www.synopsys.com/IP/ProcessorIP/ARCProcessors/arc-hs/Pages/default.aspx

* 1/2 and 2/2 account for ARCv2 differences vs. existing ARCompact ISA.

s/don;t/don't/
The new arcv2_defconfig lacks GNU_GLOB.

Do you want me to fix these 2 up before committing or do you want new patches?

* 3/4 and 4/4 fix handling of SYSCALL_ALIGN_64BIT in general.
It would seem that 4/4 is needed for any arch, but I've done this
under__arc__ to
  not possbily break other arches needing SYSCALL_ALIGN_64BIT

What a pain. Let's expand this to other arches if you think it is right. Again, 
do you want me to adjust this or can you roll v2 patches?

Thanks,

These patches will make upstream usable for ARC w/o any out-of-tree
patches.
Please consider merging.

Thx,
-Vineet


Claudiu Zissulescu (1):
  ARCv2: optimised string routines

Vineet Gupta (3):
  ARCv2 ISA support
  posix_fadvise: handle 2 variants for SYSCALL_ALIGN_64BIT
  sync_file_range: fix for UCLIBC_SYSCALL_ALIGN_64BIT

 Rules.mak  |   2 +
 extra/Configs/Config.arc   |   6 +
 extra/Configs/Config.in|   1 +
 extra/Configs/defconfigs/arc/arcv2_defconfig   |  32 +++
 include/elf.h  |   1 +
 ldso/ldso/arc/dl-sysdep.h  |  15 +-
 ldso/ldso/arc/elfinterp.c  |   4 +
libc/string/arc/arcv2/memcpy.S | 236
+
 libc/string/arc/arcv2/memset.S |  85 
 libc/string/arc/arcv2/strcmp.S |  83 
 libc/string/arc/memcmp.S   |  29 +++
 libc/sysdeps/linux/arc/bits/syscalls.h |  10 +-
 libc/sysdeps/linux/arc/bits/uClibc_arch_features.h |   7 +
 libc/sysdeps/linux/common/posix_fadvise.c  |   6 +-
 libc/sysdeps/linux/common/posix_fadvise64.c|  11 +-
 libc/sysdeps/linux/common/sync_file_range.c|   3 +-
 16 files changed, 525 insertions(+), 6 deletions(-)
 create mode 100644 extra/Configs/defconfigs/arc/arcv2_defconfig
 create mode 100644 libc/string/arc/arcv2/memcpy.S
 create mode 100644 libc/string/arc/arcv2/memset.S
 create mode 100644 libc/string/arc/arcv2/strcmp.S


___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [PATCH 1/1] Update MIPS configuration rules.

[Bernhard Reutner-Fischer]

On January 28, 2015 11:56:07 PM GMT+01:00, Steve Ellcey sell...@imgtec.com 
wrote:
Add a configuration choice for the NaN format on MIPS (either the
standard (legacy) format or the newer IEEE 2008 format.

Change how CPU_LDFLAGS are set for MIPS.  Use the same value as
CPU_CFLAGS since CC is used to do linking.  This ensures consistency
between compiles and links and adds support for N32 ABI to linking.

Applied, thanks!

___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: Build error with LINUXTHREADS_NEW and no UCLIBC_HAS_REALTIME

[Bernhard Reutner-Fischer]

On February 19, 2015 3:25:15 PM GMT+01:00, Sarah Nadi sn...@uwaterloo.ca 
wrote:
Hi,

LINUXTHREADS_NEW does not build correctly without also selecting 
UCLIBC_HAS_REALTIME since function nanosleep will be undefined. See 
attached .config for reproducing with version 0.9.33.2.

Should a select UCLIBC_HAS_REALTIME be added to LINUXTHREADS_NEW in 
Config.in similar to LINUXTHREADS_OLD?

I'll have a look during the weekend.
Thanks,

___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [PATCH] elf: Add STT_GNU_IFUNC from glibc

[Bernhard Reutner-Fischer]

On 20 February 2015 at 10:57, Vineet Gupta vineet.gup...@synopsys.com wrote:
 perf in upstream Linux kernel 3.17 onwards expects STT_GNU_IFUNC
 replicate it from glibc

Applied, thanks!
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [PATCH v2 0/4] uClibc port to ARCv2 ISA

[Bernhard Reutner-Fischer]

Hi Vineet,

We have EM_ARCOMPACT and EM_ARC_A5, can you please drop the former (and
update the sources accordingly)?

TIA,
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [PATCH] ARC: Remove unused EM_ARC_A5

[Bernhard Reutner-Fischer]

On 20 February 2015 at 12:43, Vineet Gupta vineet.gup...@synopsys.com wrote:
 Signed-off-by: Vineet Gupta vgu...@synopsys.com

Applied. Thanks, I'm feeling way better now ;)

cheers,
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [PATCH] Allow use of executable RPATH/RUNPATH when finding libraries.

[Bernhard Reutner-Fischer]

On 20 February 2015 at 08:32, Bernhard Reutner-Fischer
rep.dot@gmail.com wrote:
 On February 20, 2015 1:03:26 AM GMT+01:00, Steve Ellcey sell...@imgtec.com 
 wrote:
This option will modify ldso so that it will use the executables
RPATH/RUNPATH to find to find libraries even though this behavour
is not standard.  Setting this option causes the uclibc dynamic linker
behavour to match the glibc dynamic linker.

 Isn't RUNPATH a separate entry?

I applied something very similar to master now.

Thanks for your persistance :)
cheers,
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: Building uClibc with seperate object directory

[Bernhard Reutner-Fischer]

On 27 January 2015 at 20:26, Steve Ellcey sell...@imgtec.com wrote:
 I was wondering if anyone else builds uClibc with a seperate object
 directory using the O=object directory option?  I use this, partly
 because I come from the GCC world where a seperate object directory
 is required and partly because I build multiple uClibc libraries
 for different ABI's and want to put them in different locations.

 This was working for me several months ago but I think it is
 currently broken.  The failure mode I get is compilation errors
 while compiling ldso.c (UCLIBC_LDSO not defined) but the underlying
 problem seems to be the use of the O= option.  If I leave this out
 and build uClibc in the source directory then everything works fine.

oops, sorry for that.
Fixed on master.

Thanks for the heads-up!
cheers,
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: Compiling SELinux-enabled busybox with uClibc

[Bernhard Reutner-Fischer]

On January 14, 2015 12:45:19 AM GMT+01:00, Jan Burg bible.ma...@outlook.com 
wrote:
Hi, I'm trying to compile busybox with SELinux tools enabled and get
the following error message:

...
  LINKbusybox_unstripped
Trying libraries: crypt m selinux sepol
Failed: -Wl,--start-group  -lcrypt -lm -lselinux -lsepol 
-Wl,--end-group
Output of:
../arm-uclibc/bin/arm-buildroot-linux-uclibcgnueabi-gcc -I
../arm-uclibc/include/ -I ../libselinux-2.1.9/include/ -I
../libsepol-2.1.4/include/ -static -L ../libselinux-2.1.9/src/ -L
../libsepol-2.1.4/src/ -L ../arm-uclibc/lib -lselinux -lsepol -static
-o busybox_unstripped -Wl,--sort-common -Wl,--sort-section,alignment
-Wl,--gc-sections -Wl,--start-group applets/built-in.o archival/lib.a
archival/libarchive/lib.a console-tools/lib.a coreutils/lib.a
coreutils/libcoreutils/lib.a debianutils/lib.a e2fsprogs/lib.a
editors/lib.a findutils/lib.a init/lib.a libbb/lib.a libpwdgrp/lib.a
loginutils/lib.a mailutils/lib.a miscutils/lib.a modutils/lib.a
networking/lib.a networking/libiproute/lib.a networking/udhcp/lib.a
printutils/lib.a procps/lib.a runit/lib.a selinux/lib.a shell/lib.a
sysklogd/lib.a util-linux/lib.a util-linux/volume_id/lib.a
archival/built-in.o archival/libarchive/built-in.o
console-tools/built-in.o coreutils/built-in.o
coreutils/libcoreutils/built-in.o debianutils/bu
ilt-in.o e2fsprogs/built-in.o editors/built-in.o findutils/built-in.o
init/built-in.o libbb/built-in.o libpwdgrp/built-in.o
loginutils/built-in.o mailutils/built-in.o miscutils/built-in.o
modutils/built-in.o networking/built-in.o
networking/libiproute/built-in.o networking/udhcp/built-in.o
printutils/built-in.o procps/built-in.o runit/built-in.o
selinux/built-in.o shell/built-in.o sysklogd/built-in.o
util-linux/built-in.o util-linux/volume_id/built-in.o -Wl,--end-group
-Wl,--start-group -lcrypt -lm -lselinux -lsepol -Wl,--end-group
==
../libsepol-2.1.4/src//libsepol.a(policydb.o): In function
`symtab_insert':
policydb.c:(.text+0x2f94): undefined reference to `__assert_fail'
../libsepol-2.1.4/src//libsepol.a(policydb.o): In function
`scope_read':
policydb.c:(.text+0x873c): undefined reference to `__assert_fail'
../libsepol-2.1.4/src//libsepol.a(policydb.o): In function
`policydb_read':
policydb.c:(.text+0x9178): undefined reference to `__assert_fail'
../libsepol-2.1.4/src//libsepol.a(expand.o): In function
`alias_copy_callback':
expand.c:(.text+0x2a64): undefined reference to `__assert_fail'
../libsepol-2.1.4/src//libsepol.a(expand.o): In function
`role_fix_callback':
expand.c:(.text+0x2ea8): undefined reference to `__assert_fail'
../libsepol-2.1.4/src//libsepol.a(expand.o):expand.c:(.text+0x3068):
more undefined references to `__assert_fail' follow
collect2: error: ld returned 1 exit status
make: *** [busybox_unstripped] Error 1


I was just wandering if uClibc doesn't support SELinux, whether there
might be a patch for this, or if someone has more information on this.

__assert_fail  is a glibc thing. Make sure to compile SElinux libraries against 
uClibc.

thanks,

___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

RE: [PATCH] ARC: Add GNU glob to ARC defconfigs

[Bernhard Reutner-Fischer]

On February 13, 2015 12:26:07 PM GMT+01:00, Anton Kolesov 
anton.kole...@synopsys.com wrote:
 On Mon, Feb 09, 2015 at 02:37:11PM +, Anton Kolesov wrote:
Anton, are you going to spin a patch to that effect ?
  
   Yes.
   Anton
 
  It didn't worked quite well - glob implementation shipped with make
  sources makes some assumptions WRT of presence of __mempcpy,
  __alloca and __stat, which are not true for uClibc. I was able to
  avoid the problem by changing make/glob/glob.c: by adding there
  several #ifdef __UCLIBC__ (similar to the one found in
  libpthread/nptl_db/thread_dbP.h at line 32). But that means that
  patching of uclibc/include/gnu-versions.h is not sufficient on its
  own.
 
 This does not sound plausible. GNU make works on dozens if not
 hundreds of platforms which do not have the above glibc nonsense
 exported. Or is it using this stuff based on uclibc's defining of the
 __GLIBC__ macro?
 

1. Error for mempcpy depends on (__GLIBC__ - 0 == 2  __GLIBC_MINOR__
= 1)
(http://git.savannah.gnu.org/cgit/make.git/tree/glob/glob.c#n179).
Those conditions are met for uClibc
(http://git.uclibc.org/uClibc/tree/include/features.h#n395), as a
result make's glob  undefines mempcpy and sets it to __mempcpy.
Unfortunately __mempcpy doesn't get resolved by linker to anything.

2. For alloca
(http://git.savannah.gnu.org/cgit/make.git/tree/glob/glob.c#n211) we
need #define __alloca alloca to be done, but that doesn't happen
because condition (!defined __GNU_LIBRARY__) is false.

3. For stat it is the same: condition is #ifndef __GNU_LIBRARY__
(http://git.savannah.gnu.org/cgit/make.git/tree/glob/glob.c#n234) which
is false for uClibc, and __stat is left undefined, but is used by
glob.c.

I'm not really a libc developer so I would refrain from deciding what
is right and what is wrong with those defines, I just need make to
run uClibc testsuite and Vineet greenlighted for me enabling gnu glob
in default config for ARC.

So we will just enable the GNU glob for ARC as a quick measure and I already 
planned to look into removing our cheat after the release, thus we can easily 
disable GNU glob for the defconfig afterwards.

Thanks,

___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [RFC][PATCH] malloc:checked_request2size fail will let malloc futex locked

[Bernhard Reutner-Fischer]

On March 18, 2015 11:44:50 AM GMT+01:00, Zhiqiang Zhang 
zhangzhiqiang.zh...@huawei.com wrote:
For some rarely cases(almost App bugs), calling malloc with
a very largre size, checked_request2size check will fail,set
ENOMEM, and return 0 to caller.

But this will let __malloc_lock futex locked and owned by the
caller. In multithread circumstance, other thread calling
malloc/calloc will NOT succeed and get locked.

Testcase, please?
Are the other 2 malloc implementations affected, too?
Thanks,

___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [PATCH] resolv: fix unaligned tmp buffer corner-case

[Bernhard Reutner-Fischer]

On March 14, 2015 4:06:03 PM GMT+01:00, Rich Felker dal...@libc.org wrote:
On Thu, Mar 12, 2015 at 02:21:12AM +0300, Alexey Brodkin wrote:
 On execution of inet/gethost_r-align test I noticed failure due
 to unaligned access (instaed of 4-byte aligned 1-byte aligned
 address was attempted to be accessed).
 
 Further investigation confirmed this nice and helpful test failure.
 Following commit removed usage of ALIGN_BUFFER_OFFSET on entry to
 __read_etc_hosts_r():

http://git.uclibc.org/uClibc/commit/?id=f65e66078b9f4d2d7f0fc336dee36e78fc467c0f
 
 So indeed if target architecture doesn't allow unaligned access
 and provided tmp buffer is not word aligned (and we will deal with
pointers
 which means word-sized data units), then CPU will fail during
execution.
 
 In case of ARC we'll see Unaligned access exception like this:
  ---8---
  # potentially unexpected fatal signal 7.
  Path: /root/uClibc/test/inet/gethost_r-align
  CPU: 0 PID: 5514 Comm: gethost_r-align Not tainted 3.13.11 #2
  task: 8f42a580 ti: 8f40e000 task.ti: 8f40e000
 
  [ECR   ]: 0x00230400 = Misaligned r/w from 0x5fdab341
  [EFA   ]: 0x5fdab341
  [BLINK ]: 0x20032a18
  [ERET  ]: 0x20032a3c
  @off 0x12a3c in [/lib/libuClibc-0.9.34-git.so]
  VMA: 0x2002 to 0x20062000
  [STAT32]: 0x0086 : U E2 E1
  BTA: 0x20046014  SP: 0x5fdab260  FP: 0x
  LPS: 0x20046064 LPE: 0x20046068 LPC: 0x
  r00: 0x5fdab341 r01: 0x0005 r02: 0x0015
  r03: 0x r04: 0x5fdab358 r05: 0x
  r06: 0x0a0a0a00 r07: 0x r08: 0x003f
  r09: 0x20067050 r10: 0x r11: 0x0014
  r12: 0x0001 r13: 0x r14: 0x20060660
  r15: 0x20060661 r16: 0x0006 r17: 0x5fdab371
  r18: 0x0018 r19: 0x5fdab2b4 r20: 0x0002
  r21: 0x r22: 0x00029068 r23: 0x5fdab371
  r24: 0x0001 r25: 0x
  ---8---
 
 To fix this problem we'll re-introduce tmp buffer force alignment
 before config parser invocation.
 
 Signed-off-by: Alexey Brodkin abrod...@synopsys.com
 Cc: Vineet Gupta vgu...@synopsys.com
 Cc: Waldemar Brodkorb w...@openadk.org
 ---
  libc/inet/resolv.c | 8 +++-
  1 file changed, 7 insertions(+), 1 deletion(-)
 
 diff --git a/libc/inet/resolv.c b/libc/inet/resolv.c
 index cfc1eee..7c678ce 100644
 --- a/libc/inet/resolv.c
 +++ b/libc/inet/resolv.c
 @@ -1614,7 +1614,7 @@ int __read_etc_hosts_r(
  sizeof(struct in_addr)
  #endif
  ;
 -int ret = HOST_NOT_FOUND;
 +int i, ret = HOST_NOT_FOUND;
  
  *h_errnop = NETDB_INTERNAL;
  if (buflen  aliaslen
 @@ -1626,6 +1626,12 @@ int __read_etc_hosts_r(
  *result = NULL;
  return errno;
  }
 +
 +/* make sure pointer is aligned */
 +i = ALIGN_BUFFER_OFFSET(buf);
 +buf += i;
 +buflen -= i;

Is this safe against the possibility of bufleni? Otherwise you're
introducing a serious overflow.

The lines below read:

*h_errnop = NETDB_INTERNAL;
if (buflen  aliaslen   || (buflen - aliaslen)  BUFSZ + 1)
  return ERANGE;

So ISTM it should be OK.


___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

RE: [PATCH]mips: ldso: dlopen with flag RTLD_NOW should look up the symbols

[Bernhard Reutner-Fischer]

On February 25, 2015 10:13:02 PM GMT+01:00, Andrew Bennett 
andrew.benn...@imgtec.com wrote:

Andrew, so what do you think about Jean Lee's patch?

TIA,

___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: Broken assumptions in gen_wctype

[Bernhard Reutner-Fischer]

On March 6, 2015 8:39:41 PM GMT+01:00, Rich Felker dal...@libc.org wrote:
I just tried building uclibc (via buildroot) on my Alpine Linux
system, which is based on musl libc. I encountered some portability
issues in the locale generation code which I'll report separately
later, but the big issue I found here was a silent failure to generate
wctables.h. Looking into gen_wctype.c, I found it's failing at this
test:

   if ((l != (short)l) || (u != (short)u)) {
   verbose_msg(range assumption error!  %x  %ld  %ld\n, c, l, u);
   return EXIT_FAILURE;
   }

Apparently uclibc's locale system encodes an assumption that
towlower/towupper map a character to an offset that fits in a signed
16-bit offset. This assumption is false on the current versions of
Unicode (and even fairly old ones); at least the following characters
fail it:

char   up   low  du dl
0265 ɥ 0265 a78d 0 42280
0266 ɦ 0266 a7aa 0 42308
1d79 ᵹ 1d79 a77d 0 35332

Presumably the only reason uclibc's gen_wctype works right now on
glibc-based hosts is that glibc's Unicode alignment is severely
outdated. This is about to change; see
https://sourceware.org/ml/libc-alpha/2014-11/msg00664.html and the
thread that extends into the following months. So without a fix,
uclibc will probably break soon in the wild.

A suitable replacement assumption might be that towupper/towlower stay
in the same plane, so that instead of a signed 16-bit offset, uclibc
could use an unsigned 16-bit replacement of the low 16 bits. I have no
idea how practical this might be to implement but if it works it would
at least avoid increasing the size of the tables.

Mhm. Thanks alot for the heads-up!

Cheers,

___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [PATCH 3/4] ARC/signal: shield sa_restorer from compiler toggle side-effects

[Bernhard Reutner-Fischer]

On 26 March 2015 at 09:55, Vineet Gupta vineet.gup...@synopsys.com wrote:
 when building uClibc with -O0 (DODEBUG build) the default sigrestorer
 had some extra glue code generated for stack manipulation which was
 messing up resume from signal path.

 So annotate the function with -Os so that gcc would only generate the
 bare min 2 instruction TRAP sequence

.. which is the reason the rt_sigrestorer and default_sigrestorer are
usually implemented in a separate file (usually asm, IIRC).
I think the toplevel impl that is used in x86_64 works fine and has
the nice benefit to be in one source-file.
See e.g.: libc/sysdeps/linux/x86_64/sigaction.c

This would have avoided all the sigaction dance in
65bc357213f1c08e339757923740f5d68212cf76 and
f74294bd6768af59e33dc14c6fed41f01d0adc5b it seems, but anyway.

Do you think the x86_64 scheme makes sense for you and you can peruse it?

thanks,

 Reported-and-Debugged-by: Alexey Brodkin abrod...@synopsys.com
 Signed-off-by: Vineet Gupta vgu...@synopsys.com
 ---
  libc/sysdeps/linux/arc/sigaction.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

 diff --git a/libc/sysdeps/linux/arc/sigaction.c 
 b/libc/sysdeps/linux/arc/sigaction.c
 index 4a4c9e2d0821..3e2f91cd73e8 100644
 --- a/libc/sysdeps/linux/arc/sigaction.c
 +++ b/libc/sysdeps/linux/arc/sigaction.c
 @@ -13,7 +13,8 @@
  /*
   * Default sigretrun stub if user doesn't specify SA_RESTORER
   */
 -static void __default_rt_sa_restorer(void)
 +static void __attribute__((noinline, optimize (-Os)))
 +__default_rt_sa_restorer(void)
  {
 INTERNAL_SYSCALL_NCS(__NR_rt_sigreturn, , 0);
  }
 --
 1.9.1

 ___
 uClibc mailing list
 uClibc@uclibc.org
 http://lists.busybox.net/mailman/listinfo/uclibc
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [PATCH 3/4] ARC/signal: shield sa_restorer from compiler toggle side-effects

[Bernhard Reutner-Fischer]

On 26 March 2015 at 12:34, Vineet Gupta vineet.gup...@synopsys.com wrote:

 x86 approach solves the multi-src file issue, but we still lack dwarf unwind 
 info,
 w/o adding explicit asm CFA ops which AFAIKR our tools still don't support. 
 With C
 we get the dwarf info for free.

Ah right. Fair enough.
Please use attribute_optimize(Os) __attribute_noinline__ instead.
thanks,
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: recent utmp fix

[Bernhard Reutner-Fischer]

On April 1, 2015 7:27:47 AM GMT+02:00, Vineet Gupta 
vineet.gup...@synopsys.com wrote:
Hi Bernhard,

A recent upstream commit (see below) breaks default busybox builds as
utmp is no longer available in our default configs.

See busybox list Switch to POSIX utmpx API.
Will commit this soon if I don't hear back from Denys.

Cheers,


  CC  applets/applets.o
In file included from include/busybox.h:8:0,
 from applets/applets.c:9:
include/libbb.h:87:19: fatal error: utmp.h: No such file or directory
 # include utmp.h
   ^
compilation terminated.
make[2]: *** [applets/applets.o] Error 1
make[1]: *** [applets_dir] Error 2
make[1]: *** Waiting for unfinished jobs

commit cf80a7fc2db30364ac98be40483e599c2c243e87
Author: Bernhard Reutner-Fischer
rep.dot@gmail.commailto:rep.dot@gmail.com
Date:   Thu Mar 26 00:50:17 2015 +0100

utmp: always have at least utmpx


Do you think we need to update our uClibc/busybox configs or can the
change above be reverted.

Thx,
-Vineet
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc


___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: 0.9.33 branch development / release process

[Bernhard Reutner-Fischer]

On February 6, 2015 12:04:30 AM GMT+01:00, Bernhard Reutner-Fischer 
rep.dot@gmail.com wrote:
On February 5, 2015 6:57:53 PM GMT+01:00, Andy Voltz
andy.vo...@timesys.com wrote:
What is the current release process for uClibc?

I'm looking to bump our build system to a newer uClibc version, but
there
are no new release tags since 0.9.33.2. It seems like the 0.9.33
branch
could be treated as version 0.9.33.3, but there was never a tag, and

We will have a 0.9.33.3 off the 0.9.33 branch.

now
master is 0.9.33.4-git.

Is the process to create a branch for the version once it's
development
is
complete? I'd rather not use 0.9.33 branch if it is some abandoned /
unstable effort, but at the same time the master branch seems active
enough
to not treat as a stable release.

I consider master pretty stable and intend to have a new stable release
of a 0.9.34 off master hopefully this month.

Changing babies nappies let's make this start of march...

m68k still hitting .sgot binutils asserts though but on the plus side major 
arches seem to do well, from cursory testing.
Thanks,

___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [PATCH] sparc/clone.S: guard tcb-offsets.h include with RESET_PID

[Bernhard Reutner-Fischer]

On 3 March 2015 at 19:04, Gustavo Zacarias gust...@zacarias.com.ar wrote:
 Otherwise we have a broken scenario with non-threading builds.

Applied, thanks!
Does sparc work Ok for you?

thanks,
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

RE: [PATCH]mips: ldso: dlopen with flag RTLD_NOW should look up the symbols

[Bernhard Reutner-Fischer]

On February 23, 2015 10:23:21 PM GMT+01:00, Andrew Bennett 
andrew.benn...@imgtec.com wrote:
 Andrew, thanks for your reply. You are a mips engineer~
 I have a following example for dlopen problem, which I tested a few
days ago, 
 but I have no mips environment these days. Would you mind to test it
for me. Many thanks.

Many thanks for the testcase I will give it a try.

Which compiler and version do you use, which version of binutils and which MIPS 
ABI?

Thanks,

___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [PATCH]mips: ldso: dlopen with flag RTLD_NOW should look up the symbols

[Bernhard Reutner-Fischer]

Please do not top-post.

On February 24, 2015 2:06:28 AM GMT+01:00, Jean Lee xiaoyur...@gmail.com 
wrote:
I tested the following environment with MIPS32, with CPU BCM7429(MIPS
r3000),
(1)
mipsel-linux-uclibc-gcc 4.5.3-2.4 (compiled by Broadcom)
binutils 2.19(GNU ld (GNU Binutils) 2.19.92.20091006)
uclibc 0.9.32-1
Segment fault.
(2)
mipsel-linux-uclibc-gcc 4.5.3-2.4 (compiled by Broadcom)
binutils 2.19(GNU ld (GNU Binutils) 2.19.92.20091006)
uclibc 0.9.34 git master
Segment fault.
(3)
mipsel-linux-uclibc-gcc 4.8 (compiled by Broadcom)
binutils ?
uclibc ?
No .rel.plt segment.
(4)
mipsel-linux-uclibc-gcc 4.9 (compiled by me)
binutils 2.19(GNU ld (GNU Binutils) 2.19.92.20091006)
uclibc 0.9.32-1
Segment fault.
(5)
mips android ndk toolchain
No .rel.plt segment.

binutils-2.19 is pretty old. Does current 2.25 or master behave the same?
Let's concentrate on gcc 4.9.2 (or trunk), binutils 2.25 (or master) and uClibc 
master.

Thanks,

___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [PATCH]mips: ldso: dlopen with flag RTLD_NOW should look up the symbols

[Bernhard Reutner-Fischer]

On February 25, 2015 5:53:58 AM GMT+01:00, Jean Lee xiaoyur...@gmail.com 
wrote:


Conclusion:
All MIPS platforms never generate .rel.plt section for dynamic
libraries,
even for
GCC 4.9
binutils 2.24
any libc(uclibc, libc, bionic)

Anyone remember what happened to 
https://gcc.gnu.org/ml/gcc/2008-06/msg00670.html

or

http://marc.info/?l=linux-mipsm=121494382925231w=2

Andrew?

___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [PATCH] Do not define unimplemented functions

[Bernhard Reutner-Fischer]

On Sat, Nov 22, 2014 at 11:46:54AM +0100, Bernd Kuhls wrote:
 Bernhard Reutner-Fischer rep.dot@gmail.com wrote in 
 news:cac1bbct8gpq7jegoyddzy57iu4rb5-5fm_kvapc8survmjx...@mail.gmail.com:
 
  On 23 September 2014 15:35, Bernd Kuhls bernd.ku...@t-online.de wrote:
 
  this patch really fixes a build error with ffmpeg
  
  That sounds a bit awkward.
  
  IIRC we deliberately do not provide wrappers for those
 
 Hi,
 
 for ffmpeg this patch is no longer needed since they fixed the problem on 
 their side themselves: http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=
 4436a8f44dedc83767b3d9da9beb85d1fae2ca30

mesa3d seems to use fmax and fmin so i think it is best to just add
those few missing wrappers. I'll push this to master i a minute.

Thanks,
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [RFC][PATCH] malloc:checked_request2size fail will let malloc futex locked

[Bernhard Reutner-Fischer]

On Wed, Mar 18, 2015 at 12:05:12PM +0100, Bernhard Reutner-Fischer wrote:
 On March 18, 2015 11:44:50 AM GMT+01:00, Zhiqiang Zhang 
 zhangzhiqiang.zh...@huawei.com wrote:
 For some rarely cases(almost App bugs), calling malloc with
 a very largre size, checked_request2size check will fail,set
 ENOMEM, and return 0 to caller.
 
 But this will let __malloc_lock futex locked and owned by the
 caller. In multithread circumstance, other thread calling
 malloc/calloc will NOT succeed and get locked.
 
 Testcase, please?
 Are the other 2 malloc implementations affected, too?

Never mind, the patch is ok.

Applied, thanks!
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: sh4 build break

[Bernhard Reutner-Fischer]

On March 23, 2015 9:10:05 AM GMT+01:00, Waldemar Brodkorb w...@openadk.org 
wrote:
Hi,

the latest git does not compile anymore:

-MT libm/cosl.os -MD -MP -MF libm/.cosl.os.dep -DL_cosl
In file included from command-line:0:0:
./include/libc-symbols.h:494:25: error: '__EI_cosl' aliased to
undefined symbol '__GI_cosl'

There are a couple of related warnings before that function, fwiw.

Please try current master.

Thanks for the report!


___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [PATCH] ARC: enable more options to satisfy build requirements of applications

[Bernhard Reutner-Fischer]

On Wed, Apr 22, 2015 at 09:31:38AM +0530, Vineet Gupta wrote:
 From: Alexey Brodkin abrod...@synopsys.com
 
 As reported by Buildroot autobuilder following options were missing:

Applied, thanks!
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [Buildroot] uClibc build verbosity control

[Bernhard Reutner-Fischer]

On 28 April 2015 at 08:38, Vineet Gupta vineet.gup...@synopsys.com wrote:
 On Tuesday 28 April 2015 01:46 AM, Bernhard Reutner-Fischer wrote:

 On April 27, 2015 11:21:10 AM GMT+02:00, Waldemar Brodkorb 
 w...@openadk.orgmailto:w...@openadk.org wrote:


Hi Vineet,
Vineet Gupta wrote,



 Hi,

 uClibc verbosity control V=xx is different from other mainstream


projects: namely Busybox and Linux kernel.

These are kbuild-based, fwiw.


 To print full cmdlines (when debugging obscure toolchain issues) we


need to pass V=2 whereas kernel/busybox take V=1.



 Can this be changed (I can provide a patch) assuming this doesn't


break existing scripts upsetting some people.



 My issue is specifically when using likes of Buildroot, there's no


obvious way to get the cmdlines of uClibc and/or other projects (unless
there's some obvious way I'm missing).


 Just add V=2 to make flags used for uclibc?

 Still requires manually hacking some Makefile etc, since V=xx is tyoically 
 given at cmdline once for entire build.


diff --git a/package/uclibc/uclibc.mk b/package/uclibc/uclibc.mk
index ce9b2b4..402966c 100644
--- a/package/uclibc/uclibc.mk
+++ b/package/uclibc/uclibc.mk
@@ -359,6 +359,13 @@ UCLIBC_MAKE_FLAGS = \
  UCLIBC_EXTRA_CFLAGS=$(UCLIBC_EXTRA_CFLAGS) $(TARGET_ABI) \
  HOSTCC=$(HOSTCC)

+ifeq ($(KBUILD_VERBOSE),0)
+ UCLIBC_MAKE_FLAGS += V=0 # default anyway
+endif
+ifeq ($(KBUILD_VERBOSE),1)
+ UCLIBC_MAKE_FLAGS += V=2
+endif
+
 define UCLIBC_KCONFIG_FIXUP_CMDS
  $(call KCONFIG_SET_OPT,CROSS_COMPILER_PREFIX,$(TARGET_CROSS),$(@D)/.config)
  $(call KCONFIG_ENABLE_OPT,TARGET_$(UCLIBC_TARGET_ARCH),$(@D)/.config)

but anyway.




Good idea. Send a patch. I am pro.


 I found the terse output with just defines rather neat.
 If there is consensus that the current V=1 has no benefit then we can drop it 
 in favour of just silent 0 and fully verbose 1.


 No, the idea is to keep both V=1 and V=2, but make them like other projects.
 e.g. in kernel build, V=2 prints the single liners, while V=1 prints the 
 verbose cmdline,
 While in uClibc it's the other way around. Same with Busybox AFAIKR.

 Simple patch below addresses that, please consider applying.

Patch did not include help-text adjustment nor locale generation verbosity.
Fixed thus, please try current master.

thanks,
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [RFC] Cannot notify GDB when a new thread is created

[Bernhard Reutner-Fischer]

On April 27, 2015 3:33:35 AM GMT+02:00, Sheng Yong shengyo...@huawei.com 
wrote:
Hi, folks,

When we testing GDB on uClibc, we find that some GDB testcases cannot
pass.

Here is one of them, no-unwaited-for-left.c, could be fount here,
https://github.com/wallento/binutils-gdb/blob/master/gdb/testsuite/gdb.threads/no-unwaited-for-left.c

This testcase tests the GDB feature called scheduler-locking, which
could
allow only the current traced pthread to run, while other pthreads
stop.

At the second breakpoint (line 65), if we try to stop the new pthread,
or
switch to the new pthread, it fails.

= test case 1 ==
-bash-4.2# ./gdb no-unwaited-for-left
... ...
(gdb) b 65
Breakpoint 1 at 0x88a8: file no-unwaited-for-left.c, line 65.
(gdb) r
Starting program: /tmp/no-unwaited-for-left
[Thread debugging using libthread_db enabled]
Using host libthread_db library /tmp/lib/libthread_db.so.1.

Breakpoint 1, main () at no-unwaited-for-left.c:65
65 no-unwaited-for-left.c: No such file or directory.
(gdb) thread 2
Thread ID 2 not known.
(gdb) set scheduler-locking on
(gdb) c
Continuing.
[Thread 0xb6ffb000 (LWP 27933) exited]
No unwaited-for children left.
Cannot remove breakpoints because program is no longer writable.
Further execution is probably impossible.
(gdb) i threads
No threads.
===

However, if we `info threads' when breakpoint 2 reached, GDB behaves
different.

== test case 2 
-bash-4.2# ./gdb no-unwaited-for-left
... ...
(gdb) b 65
Breakpoint 1 at 0x88a8: file no-unwaited-for-left.c, line 65.
(gdb) r
Starting program: /tmp/no-unwaited-for-left
[Thread debugging using libthread_db enabled]
Using host libthread_db library /tmp/lib/libthread_db.so.1.

Breakpoint 1, main () at no-unwaited-for-left.c:65
65 no-unwaited-for-left.c: No such file or directory.
(gdb) i threads
[New Thread 0xb6f5e4d0 (LWP 27945)]
  Id   Target Id Frame
2Thread 0xb6f5e4d0 (LWP 27945) no-unwaited-for 0xb6fe310c in
pthread_join (threadid=3070210048, thread_return=0x0) at
libpthread/nptl/pthread_join.c:88
* 1Thread 0xb6ffb000 (LWP 27941) no-unwaited-for main () at
no-unwaited-for-left.c:65
(gdb) set scheduler-locking on
(gdb) c
Continuing.
[Thread 0xb6ffb000 (LWP 27941) exited]
No unwaited-for children left.
(gdb) i threads
  Id   Target Id Frame
2Thread 0xb6f5e4d0 (LWP 27945) no-unwaited-for 0xb6fe310c in
pthread_join (threadid=3070210048, thread_return=0x0) at
libpthread/nptl/pthread_join.c:88

The current thread Thread ID 1 has terminated.  See `help thread'.
===

This is because when new pthread is created, uClibc sometimes (?) does
not
generate a TD_CREATE event, which is caused by not setting
__nptl_initial_report_events.
As a result, the pthread info is not added to the thread_lists. But
`info
threads' could update thread_list.

The patch from glibc (from Roland McGrath) `init.c
(__nptl_initial_report_events): New
variable.'
(https://sourceware.org/git/?p=glibc.git;a=patch;f=nptl_db/td_thr_event_enable.c;h=7d9d8bd18906fdd17364f372b160d7ab896ce909)
could solve the problem, but this context of the patch needs to be
adjusted.

Could this patch be added to uClibc?

Sure, please send a tested patch with appropriate s-o-b line.

TIA,

___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [Buildroot] uClibc build verbosity control

[Bernhard Reutner-Fischer]

On April 27, 2015 11:21:10 AM GMT+02:00, Waldemar Brodkorb w...@openadk.org 
wrote:
Hi Vineet,
Vineet Gupta wrote,

 Hi,
 
 uClibc verbosity control V=xx is different from other mainstream
projects: namely Busybox and Linux kernel.
 To print full cmdlines (when debugging obscure toolchain issues) we
need to pass V=2 whereas kernel/busybox take V=1.
 
 Can this be changed (I can provide a patch) assuming this doesn't
break existing scripts upsetting some people.
 
 My issue is specifically when using likes of Buildroot, there's no
obvious way to get the cmdlines of uClibc and/or other projects (unless
there's some obvious way I'm missing).

Just add V=2 to make flags used for uclibc?


Good idea. Send a patch. I am pro.

I found the terse output with just defines rather neat.
If there is consensus that the current V=1 has no benefit then we can drop it 
in favour of just silent 0 and fully verbose 1.


___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [PATCH] _scanf.c: Implement 'm' modifier for 'c' and '[' conversions.

[Bernhard Reutner-Fischer]

On 28 April 2015 at 07:36, Max Filippov jcmvb...@gmail.com wrote:
 From: Will Newton will.new...@imgtec.com

 The current code implements the 'm' modifier only for 's'
 conversions and would cause a segfault if it was used for 'c'
 or '[' conversions. This patch extends the code to cover these
 cases too.

Could you please add some representative testcases to test/stdio/ along this?

TIA,
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [PATCH v2] _scanf.c: Implement 'm' modifier for 'c' and '[' conversions.

[Bernhard Reutner-Fischer]

On May 15, 2015 8:44:11 PM GMT+02:00, Max Filippov jcmvb...@gmail.com wrote:
On Fri, May 8, 2015 at 1:15 AM, Max Filippov jcmvb...@gmail.com
wrote:
 From: Will Newton will.new...@imgtec.com

 The current code implements the 'm' modifier only for 's'
 conversions and would cause a segfault if it was used for 'c'
 or '[' conversions. This patch extends the code to cover these
 cases too.

 The original version could write scanned data outside the passed
buffer
 because index i used in the '[' conversion handling block was
clobbered.

 Signed-off-by: Will Newton will.new...@imgtec.com
 Signed-off-by: Max Filippov jcmvb...@gmail.com
 ---
 Changes v1-v2:
 - add testcase for %[...]/%c/%m[...]/%mc.

Ping?

This is OK, will install the pending patches early next week.
Thanks!


___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: problem cross-compiling for i686

[Bernhard Reutner-Fischer]

On 11 April 2015 at 18:42, Waldemar Brodkorb w...@openadk.org wrote:
 Hi,

 while trying to compile latest git for qemu-i386 (i686),
 I get following error:
 /home/wbx/openadk/toolchain_qemu-x86_uclibc_i686/usr/bin/i686-openadk-linux-uclibc-gcc
 -Wl,-EL -Wl,--sort-common -Wl,--sort-section=alignment -m32 -shared
 -Wl,--warn-common -Wl,--warn-once -Wl,-z,combreloc -Wl,-z,relro
 -Wl,-z,now -Wl,-z,defs   -Wl,-soname=librt.so.0 -nostdlib -o
 lib/librt-0.9.34-git.so  -Wl,--whole-archive librt/librt_so.a
 -Wl,--no-whole-archive ./lib/interp.os -L./lib ./lib/libc.so
 ./lib/libdl.so ./lib/libpthread.so
 /home/wbx/openadk/toolchain_qemu-x86_uclibc_i686/usr/lib/gcc/i686-openadk-linux-uclibc/4.9.2/libgcc.a
 /home/wbx/openadk/toolchain_qemu-x86_uclibc_i686/usr/lib/gcc/i686-openadk-linux-uclibc/4.9.2/../../../../i686-openadk-linux-uclibc/bin/ld:
 ./lib/libpthread_nonshared.a(pthread_atfork.oS): relocation
 R_386_GOTOFF against undefined hidden symbol `__dso_handle' can not
 be used when making a shared object

unfortunate combination of old(ish) gcc and new gold from binutils-2.25.
Please try current master (and thanks for the report!)
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: is ARMv4T deprecated?

[Bernhard Reutner-Fischer]

On April 15, 2015 9:47:31 PM GMT+02:00, Gustavo Zacarias 
gust...@zacarias.com.ar wrote:
On 04/15/2015 07:37 AM, Bernhard Reutner-Fischer wrote:

 I cannot reproduce this.
 The arm920t eabi image seems to boot fine with qemu for a -cpu
arm926.
 
 Please send me your
 grep memcpy\.o[sS]*  log.do_compile
 The file should be somewhere around your

tmp-uclibc/work/armv4t-oe-linux-uclibceabi/uclibc/0.9.33+gitAUTOINC+*/temp/log.do_compile

I've managed to reproduce this in buildroot with the latest uclibc
snapshot.

It seems to be toolchain-related, the table goes:
gcc 4.9.2 + binutils 2.25 + uclibc 0.9.33.2 = good
gcc 4.9.2 + binutils 2.25 + uclibc snapshot = bad
gcc 4.7.4 + binutils 2.22 + both uclibc versions = good

I'll try to get more details, but i suspect gcc is at fault here.
Sergiy: which gcc version are you using?
(BTW, in BR we build uclibc in ARM mode, EABI mandates interworking and
trying to build it in THUMB mode fails because of register exhaustion,
haven't tried with snapshot).

These spill failures should be fixed on master, fyi.



___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: is ARMv4T deprecated?

[Bernhard Reutner-Fischer]

On 16 April 2015 at 00:33, Gustavo Zacarias gust...@zacarias.com.ar wrote:
 On 04/15/2015 07:20 PM, Bernhard Reutner-Fischer wrote:

   AS libc/sysdeps/linux/arm/syscall-eabi.os

 please show me that compiler invocation with V=2 ?

 -I./ldso/include -I. -Os -fstrict-aliasing -mthumb -mthumb-interwork

 In buildroot we do prebuild gcc --with-cpu, hence no need to specify
 that later (target=arm920t).
 With my patch it builds fine until the end.

So does just 4.8.4 on ARM with thumb1 need attribute_optimize(O2)
there or does -marm need it too?
What about 4.9.2 and 5 ?

thanks,
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: is ARMv4T deprecated?

[Bernhard Reutner-Fischer]

On 15 April 2015 at 22:34, Sergiy Kibrik sa...@meta.ua wrote:
 On 4/15/15 1:37 PM, Bernhard Reutner-Fischer wrote:
 On 9 April 2015 at 20:02, Sergiy Kibrik sa...@meta.ua wrote:

 On 4/8/15 10:04 AM, Bernhard Reutner-Fischer wrote:
 On April 6, 2015 10:08:57 PM GMT+02:00, Bernhard Reutner-Fischer 
 rep.dot@gmail.com wrote:
 On April 5, 2015 9:30:30 PM GMT+02:00, Sergiy Kibrik sa...@meta.ua
 wrote:
 hi All,
 Recently I've been trying to use uClibc for quite old arm920t-based
 board.

 Do you use  -mthumb-interwork ?

 yes, it's enabled by default in yocto

 I cannot reproduce this.
 The arm920t eabi image seems to boot fine with qemu for a -cpu arm926.

 isn't arm926 based on ARMv5T?

Could be. Yes, it seems it is.
There's no V4 support in qemu it seems, at least ATM.

 Please send me your
 grep memcpy\.o[sS]*  log.do_compile
 The file should be somewhere around your
 tmp-uclibc/work/armv4t-oe-linux-uclibceabi/uclibc/0.9.33+gitAUTOINC+*/temp/log.do_compile

 here it goes: http://pastebin.com/VGqf31ac

arm-poky-linux-uclibceabi-gcc -march=armv4t -marm -mthumb-interwork
-msoft-float -mlittle-endian -mthumb

I see no notion of a tune?

IIRC armv4t defaulted to arm7TDMI. Given that OE usually does not
configure for a default CPU (AFAICS) you have to pass a proper tune.

My 920t build used:
arm-oe-linux-uclibceabi-gcc -march=armv4t -mthumb  -mthumb-interwork
-O2 -mtune=arm920t

in your local.conf, try:
FULL_OPTIMIZATION = -O2 -mtune=arm920t
ARM_INSTRUCTION_SET := thumb

maybe you need some additional settings like DEFAULTTUNE TUNE_ARCH
TUNE_PKGARCH that you certainly use already.

HTH,
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: is ARMv4T deprecated?

[Bernhard Reutner-Fischer]

On 16 April 2015 at 00:13, Gustavo Zacarias gust...@zacarias.com.ar wrote:
 On 04/15/2015 05:01 PM, Bernhard Reutner-Fischer wrote:

 These spill failures should be fixed on master, fyi.

 There's still one:

 -
   AS libc/sysdeps/linux/arm/syscall-eabi.os

please show me that compiler invocation with V=2 ?

 In file included from ldso/ldso/ldso.c:1438:0:
 ldso/ldso/dl-elf.c: In function '_dl_load_elf_shared_library':
 ldso/ldso/dl-elf.c:963:1: error: unable to find a register to spill in
 class 'LO_REGS'
  }
  ^
 ldso/ldso/dl-elf.c:963:1: error: this is the insn:
 (insn 679 677 680 87 (set (reg/v:SI 5 r5 [ _v2 ])
 (lshiftrt:SI (reg:SI 634)
 (const_int 13 [0xd]))) ./ldso/include/dl-syscall.h:220 128
 {*thumb1_lshrsi3}
  (expr_list:REG_DEAD (reg:SI 634)
 (nil)))
 ldso/ldso/dl-elf.c:963: confused by earlier errors, bailing out
 Makerules:393: recipe for target 'ldso/ldso/ldso.oS' failed
 make[1]: *** [ldso/ldso/ldso.oS] Error 1
 make[1]: *** Waiting for unfinished jobs
   CC libc/sysdeps/linux/common/umount.os
 make[1]: Leaving directory
 '/home/gustavoz/b/router01/output/build/uclibc-snapshot'
 package/pkg-generic.mk:183: recipe for target
 '/home/gustavoz/b/router01/output/build/uclibc-snapshot/.stamp_built' failed
 make: ***
 [/home/gustavoz/b/router01/output/build/uclibc-snapshot/.stamp_built]
 Error 2
 -

 I've patched that away via attribute_optimize(O2) but then i hit
 another snag:

 -
   CC libc/sysdeps/linux/common/getpgrp.os
 In file included from ./include/sys/syscall.h:33:0,
  from libc/sysdeps/linux/common/sync_file_range.c:10:
 libc/sysdeps/linux/common/sync_file_range.c: In function
 '__sync_file_range_nocancel':
 ./include/bits/syscalls.h:144:16: error: conflicting types for '_v3'
register int _v3 __asm__ (v3) = _v3tmp;

yea, i've pushed a fix for that one yesterday night.

thanks,
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: is ARMv4T deprecated?

[Bernhard Reutner-Fischer]

On April 16, 2015 9:04:47 PM GMT+02:00, Sergiy Kibrik sa...@meta.ua wrote:
On 4/16/15 12:43 AM, Bernhard Reutner-Fischer wrote:
  Please send me your
  grep memcpy\.o[sS]*  log.do_compile
  The file should be somewhere around your
 
tmp-uclibc/work/armv4t-oe-linux-uclibceabi/uclibc/0.9.33+gitAUTOINC+*/temp/log.do_compile
 
  here it goes: http://pastebin.com/VGqf31ac
 arm-poky-linux-uclibceabi-gcc -march=armv4t -marm -mthumb-interwork
 -msoft-float -mlittle-endian -mthumb
 
 I see no notion of a tune?
 
 IIRC armv4t defaulted to arm7TDMI. Given that OE usually does not
 configure for a default CPU (AFAICS) you have to pass a proper tune.
 
 My 920t build used:
 arm-oe-linux-uclibceabi-gcc -march=armv4t -mthumb  -mthumb-interwork
 -O2 -mtune=arm920t
 
 in your local.conf, try:
 FULL_OPTIMIZATION = -O2 -mtune=arm920t
 ARM_INSTRUCTION_SET := thumb
 
 maybe you need some additional settings like DEFAULTTUNE TUNE_ARCH
 TUNE_PKGARCH that you certainly use already.
 

I tried -mtune=arm920t some time ago once, but it didn't help.

I changed return [from Thumb routine] code, and it did the trick, now
busybox and couple of utilities seems to be working (yet I didn't run
uclibc tests):

diff --git a/libc/sysdeps/linux/arm/bits/arm_asm.h
b/libc/sysdeps/linux/arm/bits/arm_asm.h
index 04664b3..78dc6f0 100644
--- a/libc/sysdeps/linux/arm/bits/arm_asm.h
+++ b/libc/sysdeps/linux/arm/bits/arm_asm.h
@@ -13,12 +13,8 @@
unified assembly syntax.  */
 #define IT(t, cond)
 /* Code to return from a thumb function stub.  */
-#ifdef __ARM_ARCH_4T__
-#define POP_RET pop   {r2, pc}
-#else
 #define POP_RET pop   {r2, r3}; bxr3
 #endif
-#endif

 #if defined(__ARM_ARCH_6M__)
 /* Force arm mode to flush out errors on M profile cores.  */


What do you think of such fix?

Should probably take USE_BX into account..
Other than that and a signed-off-by sure, whatever works for you!

Many TIA,


___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: is ARMv4T deprecated?

[Bernhard Reutner-Fischer]

--- a/libc/sysdeps/linux/arm/bits/arm_asm.h
+++ b/libc/sysdeps/linux/arm/bits/arm_asm.h
@@ -13,12 +13,8 @@
unified assembly syntax.  */
 #define IT(t, cond)
 /* Code to return from a thumb function stub.  */
-#ifdef __ARM_ARCH_4T__
-#define POP_RET pop   {r2, pc}
-#else
 #define POP_RET pop   {r2, r3}; bxr3
 #endif
-#endif

 #if defined(__ARM_ARCH_6M__)
 /* Force arm mode to flush out errors on M profile cores.  */


What do you think of such fix?

 Should probably take USE_BX into account..
 Other than that and a signed-off-by sure, whatever works for you!

So i read some documents yesterday night and this lead me to think
that the condition is just inverted?
Shouldn't it read more like:

 /* Code to return from a thumb function stub.  */
#if defined __ARM_ARCH_4T__ /*  defined __THUMB_INTERWORK__ */
# define POP_RET pop   {r2, r3}; bxr3
#else
# define POP_RET pop   {r2, pc}
#endif

thanks,

 Many TIA,


___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: is ARMv4T deprecated?

[Bernhard Reutner-Fischer]

On 17 April 2015 at 14:32, Bernhard Reutner-Fischer
rep.dot@gmail.com wrote:

 So i read some documents yesterday night and this lead me to think
 that the condition is just inverted?
 Shouldn't it read more like:

May i ask you to try the attached on your arm920t, please?

This should of course be tested in pure ARM mode too..

TIA  cheers,
diff --git a/include/libc-symbols.h b/include/libc-symbols.h
index a87cde6..97463ac 100644
--- a/include/libc-symbols.h
+++ b/include/libc-symbols.h
@@ -111,7 +111,7 @@
 /* Indirect stringification.  Doing two levels allows
  * the parameter to be a macro itself.
  */
-#define __stringify_1(x)#x
+#define __stringify_1(x...)#x
 #define __stringify(x)  __stringify_1(x)
 
 #ifdef __UCLIBC_HAVE_ASM_SET_DIRECTIVE__
diff --git a/ldso/ldso/arm/dl-startup.h b/ldso/ldso/arm/dl-startup.h
index df2c824..eb2a9a2 100644
--- a/ldso/ldso/arm/dl-startup.h
+++ b/ldso/ldso/arm/dl-startup.h
@@ -47,11 +47,7 @@ __asm__(
 		ldr	r0, .L_FINI_PROC\n
 		ldr	r0, [sl, r0]\n
 		@ jump to the user_s entry point\n
-#if defined(__USE_BX__)
-		bx	r6\n
-#else
-		mov	pc, r6\n
-#endif
+		 __stringify(BX(r6)) \n
 	.L_GET_GOT:\n
 		.word	_GLOBAL_OFFSET_TABLE_ - .L_GOT_GOT - 4\n
 	.L_SKIP_ARGS:\n
@@ -113,11 +109,7 @@ __asm__(
 		ldr	r0, .L_FINI_PROC\n
 		ldr	r0, [r7, r0]\n
 		@ jump to the user_s entry point\n
-#if defined(__USE_BX__)
-		bx	r6\n
-#else
-		mov	pc, r6\n
-#endif
+		 __stringify(BX(r6)) \n
 	\n\n
 	.L_GET_GOT:\n
 		.word	_GLOBAL_OFFSET_TABLE_ - .L_GOT_GOT - 4\n
diff --git a/ldso/ldso/arm/resolve.S b/ldso/ldso/arm/resolve.S
index c1caf9a..7e0058e 100644
--- a/ldso/ldso/arm/resolve.S
+++ b/ldso/ldso/arm/resolve.S
@@ -90,12 +90,10 @@
  * dl-startup.c).
  */
 
-#include sys/syscall.h
+#include features.h
 #include bits/arm_asm.h
 #include bits/arm_bx.h
 
-#include features.h
-
 #define sl r10
 #define fp r11
 #define ip r12
@@ -114,8 +112,8 @@ _dl_linux_resolve:
  @ function must branch to the real function, and that expects
  @ r0-r3 and lr to be as they were before the whole PLT stuff -
  @ ip can be trashed.
-	 @ This routine is called after pushing lr, so we must push an odd
-	 @ number of words to keep the stack correctly aligned.
+ @ This routine is called after pushing lr, so we must push an odd
+ @ number of words to keep the stack correctly aligned.
 
  stmdb sp!, {r0, r1, r2, r3, r4}
  ldr r0, [lr, #-4]   @ r0 := [lr-4] (GOT_TABLE[1])
@@ -124,16 +122,12 @@ _dl_linux_resolve:
  @ ~x = -x-1, therefore ~(r12) = (-((lr-ip)2)-1)
  @ = - ((lr-ip)/4) - 1 = (ip - lr - 4)/4, as required
 
-	bl _dl_linux_resolver
+bl _dl_linux_resolver
 
-	mov ip, r0
+mov ip, r0
 ldmia sp!, {r0, r1, r2, r3, r4, lr}
 
-#if defined(__USE_BX__)
-	bx ip
-#else
-	mov pc,ip
-#endif
+BX(ip)
 #else
@ In the thumb case _dl_linux_resolver is thumb.  If a bl is used
@ from arm code the linker will insert a stub call which, with
diff --git a/libc/string/arm/_memcpy.S b/libc/string/arm/_memcpy.S
index c59f5b8..2999e8e 100644
--- a/libc/string/arm/_memcpy.S
+++ b/libc/string/arm/_memcpy.S
@@ -111,11 +111,7 @@ _memcpy:
 	bcc	.Lmemcpy_backwards
 
 	IT(t, eq)			/* Quick abort for src=dst */
-#if defined(__USE_BX__)
-bxeqlr
-#else
-moveq   pc, lr
-#endif
+	BXC(eq, lr)
 	stmdb	sp!, {r0, lr}		/* memcpy() returns dest addr */
 	subs	r2, r2, #4
 	blt	.Lmemcpy_fl4		/* less than 4 bytes */
@@ -455,11 +451,7 @@ _memcpy:
 	/* less than 4 bytes to go */
 	adds	r2, r2, #4
 	IT(t, eq)
-#if defined(__USE_BX__)
-bxeqlr
-#else
-	moveq	pc, lr			/* done */
-#endif
+	BXC(eq, lr)			/* done */
 	/* copy the crud byte at a time */
 	cmp	r2, #2
 	ldrb	r3, [r1, #-1]!
@@ -477,11 +469,7 @@ _memcpy:
 	ldrgtb	r3, [r1, #-1]!
 	strgtb	r3, [r0, #-1]!
 #endif
-#if defined(__USE_BX__)
-bx  lr
-#else
-	mov	pc, lr
-#endif
+	BX(lr)
 	/* erg - unaligned destination */
 .Lmemcpy_bdestul:
 	cmp	r12, #2
diff --git a/libc/string/arm/memcmp.S b/libc/string/arm/memcmp.S
index 9f78415..5b9473c 100644
--- a/libc/string/arm/memcmp.S
+++ b/libc/string/arm/memcmp.S
@@ -67,11 +67,7 @@ memcmp:
 	subs	r2, r2, #1
 	IT(tt, mi)
 	movmi	r0, #0
-#if defined(__USE_BX__)
-bxmilr
-#else
-	movmi	pc, lr
-#endif
+	BXC(mi, lr)
 	/* ip == last src address to compare */
 	add	ip, r0, r2
 1:
@@ -82,11 +78,7 @@ memcmp:
 	cmpcs	r2, r3
 	beq	1b
 	sub	r0, r2, r3
-#if defined(__USE_BX__)
-bx  lr
-#else
- 	mov	pc, lr
-#endif
+	BX(lr)
 #endif
 
 .size memcmp,.-memcmp
diff --git a/libc/string/arm/memset.S b/libc/string/arm/memset.S
index 8ddc47e..2be4850 100644
--- a/libc/string/arm/memset.S
+++ b/libc/string/arm/memset.S
@@ -17,7 +17,6 @@
http://www.gnu.org/licenses/.  */
 
 #include features.h
-#include sys/syscall.h
 #include bits/arm_asm.h
 #include bits/arm_bx.h
 
@@ -109,11 +108,7 @@ memset:
 2:
 	movs	a3, a3		@ anything left?
 	IT(t

Re: is ARMv4T deprecated?

[Bernhard Reutner-Fischer]

On April 17, 2015 8:54:06 PM GMT+02:00, Sergiy Kibrik sa...@meta.ua wrote:
On 4/17/15 6:59 PM, Bernhard Reutner-Fischer wrote:
 On 17 April 2015 at 14:32, Bernhard Reutner-Fischer
 rep.dot@gmail.com wrote:
 
 So i read some documents yesterday night and this lead me to think
 that the condition is just inverted?
 Shouldn't it read more like:
 
 May i ask you to try the attached on your arm920t, please?
 
 This should of course be tested in pure ARM mode too..
 

sure. It seems to be working fine on arm920t in both thumb-interwork 
arm-only modes (however I can't try on other hardware currently).

Excellent, thanks a lot for testing!

Cheers,

___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: is ARMv4T deprecated?

[Bernhard Reutner-Fischer]

On 9 April 2015 at 20:02, Sergiy Kibrik sa...@meta.ua wrote:

 On 4/8/15 10:04 AM, Bernhard Reutner-Fischer wrote:
 On April 6, 2015 10:08:57 PM GMT+02:00, Bernhard Reutner-Fischer 
 rep.dot@gmail.com wrote:
 On April 5, 2015 9:30:30 PM GMT+02:00, Sergiy Kibrik sa...@meta.ua
 wrote:
 hi All,
 Recently I've been trying to use uClibc for quite old arm920t-based
 board.

 Do you use  -mthumb-interwork ?

 yes, it's enabled by default in yocto

I cannot reproduce this.
The arm920t eabi image seems to boot fine with qemu for a -cpu arm926.

Please send me your
grep memcpy\.o[sS]*  log.do_compile
The file should be somewhere around your
tmp-uclibc/work/armv4t-oe-linux-uclibceabi/uclibc/0.9.33+gitAUTOINC+*/temp/log.do_compile

TIA,
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: is ARMv4T deprecated?

[Bernhard Reutner-Fischer]

On April 6, 2015 10:08:57 PM GMT+02:00, Bernhard Reutner-Fischer 
rep.dot@gmail.com wrote:
On April 5, 2015 9:30:30 PM GMT+02:00, Sergiy Kibrik sa...@meta.ua
wrote:
hi All,
Recently I've been trying to use uClibc for quite old arm920t-based
board.

Do you use  -mthumb-interwork ?

Thanks,

___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [PATCH 0/6] h8300 update

[Bernhard Reutner-Fischer]

On 18 May 2015 at 09:32, Yoshinori Sato ys...@users.sourceforge.jp wrote:
 Hello.

 H8/300's linux v4 using new toolchain.
 This patch is supported new toolchain.
 And clean up obsolete code.

You should drop ARCH_WANT_IPC_PARSE_VERSION from your kernel.

Please consider switching your kernel to use the simplified
asm-generic/unistd.h and remove ARCH_HAS_DEPRECATED_SYSCALLS from your
uClibc-port.
(It seems you already do that in your kernel, don't you).

Why ARCH_HAS_NO_LDSO ? Do you plan to add it later?

[PATCH 4/6] h8300: headers update
The fcntl.h changes are not ok, please don't revert [GS]ET_PIPE_SZ.
Essentially you just want to add O_NOATIME and O_CLOEXEC and that's
all (also no need for the uio.h inclusion, IIRC),

+#define __UCLIBC_ASM_LINE_SEP__ !
you sure? :)

[PATCH 5/6] h8300: Add new feature
Please change the license to LGPL v2.1 or later
ofsfet supposedly does not compile. How did you test that? :)
We nowadays have a libc/sysdeps/linux/common/posix_fadvise64.c maybe
you just need to setup your arch WRT 64bit alignment and add it to the
list, instead?

Thanks in advance and cheers,
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: Locales strike back

[Bernhard Reutner-Fischer]

On June 2, 2015 6:03:55 PM GMT+02:00, Jaromír Cápík tav...@seznam.cz wrote:
Jaromír, your mailer is configured oddly, you insert lots of vertical space, 
fwiw.

Well. You can mix two licenses in the sources.  You just need to upload

two separate license files and put a clarification in the sources
(usually

in the headers). Many projects do that.


I could ask our legal department to get it confirmed.




 license and therefore you can freely redistribute and modify
 sources and even binary data.

And if you redistribute binaries without the corresponding sources you
get a shakedown from the FSF or the Conservancy asking for many
thousands of dollars.

Anybody can provide a tarball of an old glibc tarball if they use pregenerated 
locales, yes.



I don't see a problem with re-distributing the glibc sources :]

It might seem a bit odd, but who cares if that works.

Anyway ... in this case it' implicated as the extracting

tools produce derived sources (even when they contain binary

data), but still ... these are derived sources and not directly

re-distributed binaries. This is also a nice question for the

legal department.






  and I _really_ didn't want to throw a glibc source tarball in the
  uclbic download directory.

 I don't think you need to. 


We would need to or delete the pregenerated tarball. I'll do the latter for 
simplicity when I'm near a real computer. It's easy to recreate it against a 
let's say glibc-2.19 or .20

The email is a bit long and I'll have to read the rest later :]

Ideally we would base off the Unicode tables to avoid the whole brittle mess. 
But then that's a lot of work for something (locales) I personally see no real 
benefit in and don't really use although I see that folks seem to use it (for 
reasons beyond my imagination).

Any help to beat locales into reasonable shape is very, very welcome, of 
course. I don't see how I would find time to handle this on myself anytime soon.

So, if you use locales, please share your solutions or attempts.

Thanks and cheers,

___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: Question: Does uclibc support NPTL TLS ?

[Bernhard Reutner-Fischer]

On May 27, 2015 11:10:53 AM GMT+02:00, Sheng Yong shengyo...@huawei.com wrote:
Hi,

I encountered a problem when I test thread local storage
on my arm board (kernel 3.10.77 and uclibc 0.99.3.2).

That version dies not sound familiar. I suggest you ask whoever provided this 
release. Alternatively try current master, a recent GCC and GDB.

Thanks,

___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: Question: Does uclibc support NPTL TLS ?

[Bernhard Reutner-Fischer]

On 28 May 2015 at 04:00, Khem Raj raj.k...@gmail.com wrote:

 Seems like gdb is not able to comprehend the TLS structure that uclibc is 
 putting. So you need to investigate
 that part, either gdb or libthread-db may be where the issue lies.

OE essentially produces broken libs for the uClibc package due to
--strip-unneeded.
I have tweaked my split_and_strip_files() but as a quick-fix you might
want to enable DOSTRIP in the uClibc .config and add
INHIBIT_PACKAGE_STRIP := 1 to meta/recipes-core/uclibc/uclibc.inc

thanks,
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: Segmentation fault in __uClibc_main on m68k

[Bernhard Reutner-Fischer]

On 29 May 2015 at 13:11, Jaromír Cápík tav...@seznam.cz wrote:
 Hello.

 I'm trying to port my uClibc based distro to m68k and experience
 SIGSEGV in __uClibc_main even when linking binaries statically.

 I tried to crosscompile the m68k toolchain on i386 (uClibc based)
 and m68k (glibc based) and in both cases the resulting binaries
 segfault.

 My biggest sin is that I'm building version 0.9.28 and not the latest
 one as the i386 version of my distro has that version and I didn't
 want to be inconsistent. Anyway, I'm not against the idea of trying
 the latest version, but before doing so I'd like to know whether
 someone on this mailing list can confirm this is a known issue,
 that has been fixed somewhere between 0.9.28 and 0.9.33.2.
 I noticed changes in the libc/sysdeps/linux/m68 directory, but
 I'm unsure whether that can play a role. At least the syscall is
 redesigned completely (it was missing in 0.9.28 and I had to
 hack it using a C source from Internet).

 I would appreciate your help / hints / anything.

A m68k (cf) smallish distro bootstrapped fine with current master a
couple of weeks ago.
I did not run it through aranym though. Patches are of course welcome!

cheers,
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: Segmentation fault in __uClibc_main on m68k

[Bernhard Reutner-Fischer]

On 29 May 2015 at 17:54, Jaromír Cápík tav...@seznam.cz wrote:

 You mentioned a distro you boottrapped a couple of weeks
 ago. Do you have a working rootfs environment I could
 test?

I did not submit the m68k patch to OE yet since i meant to get gmp
going first, no.

Buildroot, Alpine-linux or gentoo come to mind, i'd try these with
current uClibc master.

HTH,
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [PATCH] NPTL/arc: notify kernel of the TP value

[Bernhard Reutner-Fischer]

On Tue, Jun 30, 2015 at 05:46:56PM +0530, Vineet Gupta wrote:
 Native gdb makes a ptrace (GET_THREAD_AREA) which needs to return the
 TP. however when libc sets up TP reg (for main thread), it doesn't call
 arc_settls syscall so kernel doesn't know of TP register details
 (moreso because clone doesnt have SETTLS flag)
 
 Note that kernel doesn't know about r25 being TP etc.
 
 This commit got lost in merge of NPTL tools into arc-mainline-dev and
 showed up again as STAR 9000919529 (native gdb can't debug threaded
 apps)
 
   ---8---
   [ARCLinux]# gdb ./pth
   Reading symbols from ./pth...(no debugging symbols found)...done.
   (gdb) b main
   Breakpoint 1 at 0x106f2
   (gdb) r
   Starting program: /pth
   [Thread debugging using libthread_db enabled]
   Using host libthread_db library /lib/libthread_db.so.1.
   thread_get_info_callback: cannot get thread info: generic error
   (gdb) q
   ---8---

Applied, thanks!
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [PATCH] siginfo: add signal info for seccomp related SIGSYS

[Bernhard Reutner-Fischer]

On Sun, May 17, 2015 at 10:49:23PM +0200, Daniel Golle wrote:
 uClibc doesn't define signal info for the SIGSYS signal which is issued
 in case of hitting a syscall prohibited by seccomp.
 This is sad as it makes debugging seccomp filter policies impossible on
 some architectures (at least ARM and PowerPC, maybe also others) which
 do not coincidentally set si_value.sival_int as the syscall number.
 
 To fix this, import the definitions and macros needed from glibc.

Applied, thanks!
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [PATCH] ARC: enable IPv6 in defconfigs

[Bernhard Reutner-Fischer]

On Mon, May 25, 2015 at 01:50:42PM +0300, Alexey Brodkin wrote:
 These days IPv6 is used more and more in different software
 packages. And so we're adding IPv6 support by default in uClibc
 for ARC cores.

Applied, thanks!
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [PATCH] test/silly: Extend include path.

[Bernhard Reutner-Fischer]

On Fri, May 08, 2015 at 10:30:37AM +, Vineet Gupta wrote:
 On Thursday 07 May 2015 08:42 PM, Andrew Burgess wrote:
  When attempting to build uClibc under buildroot, including building the
  tests, the silly tests don't currently compile, a result of attempting
  to build using a compiler that does not yet have an installed version of
  uClibc available.  The error is a missing header file, specifically
  atomic.h.
  
  Taking inspiration from the nptl tests, I have extended the EXTRA_CFLAGS
  variable to add the required include paths.  The tests can now be built
  under buildroot.
  
  Signed-off-by: Andrew Burgess andrew.burg...@embecosm.com
 
 Acked-by: Vineet Gupta vgu...@synopsys.com

Applied, thanks!
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: Segmentation fault in __uClibc_main on m68k

[Bernhard Reutner-Fischer]

On July 31, 2015 9:59:48 AM GMT+02:00, Thorsten Glaser t.gla...@tarent.de 
wrote:
On Thu, 30 Jul 2015, Bernhard Reutner-Fischer wrote:

 We are happy to take tested patches to update stuff for sure!

Hm, okay. All my patches go via Waldemar, who’s the one having
the hardware and tests anyway. They then end up in µClibc-ng.
Make out of that what you want… I’m not the user, just the low-
level hacker helping out.

bye,
//mirabilos
-- 
Yes, I hate users and I want them to suffer.
   -- Marco d'Itri on gmane.linux.debian.devel.general

Well, I don't. Choose your weapons.

___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [PATCH v2] nptl: remove duplicate vfork() in libpthread

[Bernhard Reutner-Fischer]

On July 24, 2015 9:17:27 AM GMT+02:00, Vineet Gupta 
vineet.gup...@synopsys.com wrote:
On Friday 24 July 2015 09:26 AM, Bernhard Reutner-Fischer wrote:
 On July 22, 2015 5:05:34 PM GMT+02:00, Alexey Brodkin
alexey.brod...@synopsys.com wrote:
 Hi Bernard,
 This patch indeed fixes problems with duplicate vfork in both libc
and
 libpthread.
 I'm wondering if there's a chance for this patch to be applied
still?
 Well, but it's wrong, isn't it. 

Is it ? It makes pthread also use the libc version. The only difference
between
them was pthread version had a small optimization which could be done
away
altogether with if u read thru the tread below.

https://sourceware.org/ml/libc-alpha/2014-05/msg00238.html

 pt-vfork.o should instead live in, say,  libpthread_nonshared.a and
be at the end of the libs so it is picked up by the linker when static
linking, no?

Could be done that way too but not needed if above is sufficient.

Above makes RESET_PID superfluous, doesn't it.

Care to send an updated patch?
Thanks,

-Vineet


___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: Segmentation fault in __uClibc_main on m68k

[Bernhard Reutner-Fischer]

On July 27, 2015 11:15:40 AM GMT+02:00, Thorsten Glaser t.gla...@tarent.de 
wrote:
Rob Landley rob at landley.net writes:

 support, a tangled mess of headers copied from random glibc
snapshots,

Not to mention lack of later bugfixes from glibc.

 was never a priority because glibc was inherently so much worse that
 just not being a gnu project made it smell like roses in comparison.
I
 complained about this crap over the course of many years. I didn't
stop

glibc still stinks, but µClibc(-ng) stinks like an old glibc
in many parts. (I fixed several deep bugs and incompatibilities
with current compilers in it for wbx, despite telling him to just
use musl instead, so I know.) Lots of files claim they are part
of glibc, yet they have bugs glibc fixed, so, all the bad of it
without all the good of it.

bye,
//mirabilos (who’s fixed bugs in all Linux libcs except musl, so far)

We are happy to take tested patches to update stuff for sure!
This is a community driven project since ages now. 
Send your patches and contribute or don't and just use it if it works fine for 
you, it's that simple. If you regularly contribute several good patches we 
remove the filter by giving you instamt write access, see 
http://uclibc.org/developing.html#contrib
TIA and cheers,

___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [RFC PATCH] nptl_db/db_info: fix the incorrect initial size for dtvp

[Bernhard Reutner-Fischer]

On August 7, 2015 4:28:10 AM GMT+02:00, Junling Zheng zhengjunl...@huawei.com 
wrote:
Ping again...

Sorry for the delay, will apply the outstanding patches this weekend.

Cheers,

This patch fixed the following issue:
http://lists.uclibc.org/pipermail/uclibc/2015-May/048966.html

Does anybody suffer this problem ?

On 2015/7/31 18:37, Junling Zheng wrote:
 Ping...
 
 On 2015/7/20 21:33, Junling Zheng wrote:
 When debugging a program on ARMv7 with thread-local storage declared
using
 __thread, attempting to print a thread-local variable will result
in the
 following message:

 Cannot find thread-local storage for Thread snip (LWP snip),
executable
 file /tmp/tls: capability not available

 This can be traced back to uclibc
libpthread/nptl_db/td_thr_tls_get_addr.c
 which gdb uses to look up the address of the TLS. The function
returns
 TD_NOCAPAB due to a mismatch in size between the DTV pointer and the
size
 recorded in the db description. The problem lies in
libpthread/nptl_db/db_info.c
 which initializes the db with the sizeof the union dtv. Instead it
should
 be the sizeof a pointer to union dtv.

 Fixed the initial size for dtvp to sizeof a pointer, instead of
sizeof
 the union.

 Refer to:
 http://sourceware.org/ml/libc-alpha/2006-10/msg00088.html

https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=416b630981788c1f08e746e19765aa0e5c2a1360

 Signed-off-by: Junling Zheng zhengjunl...@huawei.com
 ---
  libpthread/nptl_db/db_info.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/libpthread/nptl_db/db_info.c
b/libpthread/nptl_db/db_info.c
 index a57a053..159a027 100644
 --- a/libpthread/nptl_db/db_info.c
 +++ b/libpthread/nptl_db/db_info.c
 @@ -60,7 +60,7 @@ extern bool __nptl_initial_report_events;
 i.e. at the very end of the area covered by TLS_PRE_TCB_SIZE. 
*/
  DESC (_thread_db_pthread_dtvp,
TLS_PRE_TCB_SIZE + offsetof (tcbhead_t, dtv)
 -  - (TLS_TCB_SIZE == 0 ? sizeof (tcbhead_t) : 0), union dtv)
 +  - (TLS_TCB_SIZE == 0 ? sizeof (tcbhead_t) : 0), union dtv *)
  #endif
  
  

 
 
 ___
 uClibc mailing list
 uClibc@uclibc.org
 http://lists.busybox.net/mailman/listinfo/uclibc
 
 


___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc


___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [PATCH v2] nptl: remove duplicate vfork() in libpthread

[Bernhard Reutner-Fischer]

On July 22, 2015 5:05:34 PM GMT+02:00, Alexey Brodkin 
alexey.brod...@synopsys.com wrote:
Hi Bernard,

This patch indeed fixes problems with duplicate vfork in both libc and
libpthread.
I'm wondering if there's a chance for this patch to be applied still?

Well, but it's wrong, isn't it. pt-vfork.o should instead live in, say,  
libpthread_nonshared.a and be at the end of the libs so it is picked up by the 
linker when static linking, no?

Thanks,

___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [PATCH 1/2] libc: fix setting return value and errno in fallocate()

[Bernhard Reutner-Fischer]

On September 16, 2015 9:20:31 PM GMT+02:00, Waldemar Brodkorb 
 wrote:
>Hi Yuriy,
>
>can you explain why these patches are useful?

posix_fallocate does not set errno, the non-standard, Linux fallocate does, 
according to its manpage (and returns -1 upon error).

>Better standard conformance? Testsuite or runtime fixes?

So at least the former. Should double check not to regress the posix variant.. 
( or maybe that's a bug in the standard, didn't look yet).

HTH,
>
>Thanks
> Waldemar


___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [PATCH v2] nptl: remove duplicate vfork() in libpthread

[Bernhard Reutner-Fischer]

On September 17, 2015 12:09:17 AM GMT+02:00, Vineet Gupta 
<vineet.gup...@synopsys.com> wrote:
>Hi Bernhard,
>
>
>On Tuesday 04 August 2015 01:42 AM, Vineet Gupta wrote:
>> On Friday 31 July 2015 12:23 AM, Bernhard Reutner-Fischer wrote:
>>> On July 24, 2015 9:17:27 AM GMT+02:00, Vineet Gupta
><vineet.gup...@synopsys.com> wrote:
>>>> On Friday 24 July 2015 09:26 AM, Bernhard Reutner-Fischer wrote:
>>>>> On July 22, 2015 5:05:34 PM GMT+02:00, Alexey Brodkin
>>>> <alexey.brod...@synopsys.com> wrote:
>>>>>>> Hi Bernard,
>>>>>>> This patch indeed fixes problems with duplicate vfork in both
>libc
>>>> and
>>>>>>> libpthread.
>>>>>>> I'm wondering if there's a chance for this patch to be applied
>>>> still?
>>>>> Well, but it's wrong, isn't it. 
>>>> Is it ? It makes pthread also use the libc version. The only
>difference
>>>> between
>>>> them was pthread version had a small optimization which could be
>done
>>>> away
>>>> altogether with if u read thru the tread below.
>>>>
>>>> https://sourceware.org/ml/libc-alpha/2014-05/msg00238.html
>>>>
>>>>> pt-vfork.o should instead live in, say,  libpthread_nonshared.a
>and
>>>> be at the end of the libs so it is picked up by the linker when
>static
>>>> linking, no?
>>>>
>>>> Could be done that way too but not needed if above is sufficient.
>>> Above makes RESET_PID superfluous, doesn't it.
>> 
>> RESET_PID applies to clone; while{SAVE,RESTORE}_PID apply to vfork. I
>presume u
>> meant latter ? Perhaps clone can be tweaked too - but thats for
>another patch !
>> 
>> Assuming above is correct, you want those macros to be removed from
>> nptl/*/**/vfork.S as well as libc/sysdeps/linux/*/vfork.S and
>preferably replace
>> with a comment in case of latter set of files.
>> 
>> Can this be done in 2 steps, so the first patch from Waldemar be
>applied as it is
>> and then we do the cleanup to remove _PID from all the files (or is
>it too much
>> churn cross arches)

2-step is fine for me too, as you prefer.

>> 
>> After this, it would be even better if we get rid of the vfork files
>in NPTL as it
>> is confusing at best (as file building for libc resides in thread
>library). Why

Yes, the only reason was the PID handling, AFAIR.
Thanks,

___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [PATCH 1/2] libc: fix setting return value and errno in fallocate()

[Bernhard Reutner-Fischer]

On September 17, 2015 6:07:38 PM GMT+02:00, Rich Felker  wrote:
>On Thu, Sep 17, 2015 at 03:56:55PM +, Yuriy Kolerov wrote:
>> Hi Waldemar and Bernhard.
>> 
>> First of all sorry for the absent of the detailed explanation of my
>> fixes. I'm going to send a second version of patches after our
>> discussion.
>> 
>> The problem is that fallocate does not pass LTP (Linux Test Project)
>> which checks return code and errno after fallocate execution. Then
>> I've found that fallocate in uClibc does not set errno thus I've
>> decided to fix it according to Linux manpage. But thanks to Bernhard
>> I've also found that posix_fallocate has another behavior:
>> "posix_fallocate() returns zero on success, or an error number on
>> failure. Note that errno is not set." And posix_fallocate in uClibc
>> refers to fallocate (oops). So my first patch is invalid in this
>> place: it's also necessary to change posix_fallocate and
>> posix_fallocate64 to meet requirements of POSIX (make it don't touch
>> errno and just return error code).
>
>Not-touching-errno is not a POSIX requirement. This is just a case of
>an over-aggressive man page documenting glibc-specific behavior that
>is not standard and should not be relied upon by applications.

Right.

> You can
>see here that there is no such requirement (by default any function in
>the standard is allowed to modify errno unless it's specified not to):

Where's that written?

http://pubs.opengroup.org/onlinepubs/9699919799/functions/errno.html

posix_fallocate does not mention it so errno is unspecified after such a call, 
AFAICS.

Thanks,

>
>http://pubs.opengroup.org/onlinepubs/9699919799/functions/posix_fallocate.html
>
>Rich


___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

RE: [PATCH 1/2] libc: fix setting return value and errno in fallocate()

[Bernhard Reutner-Fischer]

On September 17, 2015 6:16:48 PM GMT+02:00, Yuriy Kolerov 
<yuriy.kole...@synopsys.com> wrote:
>Hi Rich.
>
>fallocate must return 0 or -1. However posix_fallocate my return an
>error code. So I think it would be better to allow posix_fallocate
>change errno as fallocate does it and fix posix_fallocate return value
>according to POSIX.

fallocate () should be implemented on top of posix_fallocate, yes.

TIA,
>
>Regards,
>Yuriy Kolerov
>
>
>-Original Message-
>From: Rich Felker [mailto:dal...@aerifal.cx] On Behalf Of Rich Felker
>Sent: Thursday, September 17, 2015 7:08 PM
>To: Yuriy Kolerov
>Cc: Bernhard Reutner-Fischer; Waldemar Brodkorb; uclibc@uclibc.org;
>vineet.gup...@synopsys.com; alexey.brod...@synopsys.com;
>francois.bed...@synopsys.com
>Subject: Re: [PATCH 1/2] libc: fix setting return value and errno in
>fallocate()
>
>On Thu, Sep 17, 2015 at 03:56:55PM +, Yuriy Kolerov wrote:
>> Hi Waldemar and Bernhard.
>> 
>> First of all sorry for the absent of the detailed explanation of my 
>> fixes. I'm going to send a second version of patches after our 
>> discussion.
>> 
>> The problem is that fallocate does not pass LTP (Linux Test Project) 
>> which checks return code and errno after fallocate execution. Then 
>> I've found that fallocate in uClibc does not set errno thus I've 
>> decided to fix it according to Linux manpage. But thanks to Bernhard 
>> I've also found that posix_fallocate has another behavior:
>> "posix_fallocate() returns zero on success, or an error number on 
>> failure. Note that errno is not set." And posix_fallocate in uClibc 
>> refers to fallocate (oops). So my first patch is invalid in this
>> place: it's also necessary to change posix_fallocate and
>> posix_fallocate64 to meet requirements of POSIX (make it don't touch 
>> errno and just return error code).
>
>Not-touching-errno is not a POSIX requirement. This is just a case of
>an over-aggressive man page documenting glibc-specific behavior that is
>not standard and should not be relied upon by applications. You can see
>here that there is no such requirement (by default any function in the
>standard is allowed to modify errno unless it's specified not to):
>
>http://pubs.opengroup.org/onlinepubs/9699919799/functions/posix_fallocate.html
>
>Rich


___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: Unwinding info for cancellable syscalls

[Bernhard Reutner-Fischer]

On September 14, 2015 4:02:56 AM GMT+02:00, Max Filippov  
wrote:
>Hello,
>
>I've noticed that several NPTL tst-cancelx* tests fail on ARM, because
>functions
>invoking cancellable syscalls are compiled without
>-fasynchronous-unwind-tables
>making it impossible for the libgcc DWARF unwinder to unwind stack past
>the
>syscall and call the cleanup routine. They work on x86_64, because
>x86_64 gcc
>has -fasynchronous-unwind-tables enabled by default, and on xtensa
>because it
>uses custom unwinding code. I haven't checked, but AFAIU it should fail
>on other
>architectures that use DWARF unwinder. Can anybody confirm that?
>
>I guess that at least all functions that invoke cancellable syscalls
>need to be built
>with -fasynchronous-unwind-tables in their CFLAGS. I've tried that
>with couple of
>functions and it fixes corresponding tests. And that's what glibc does
>in
>nptl/Makefile. Does that sound right for uClibc?

It does.
TIA,


___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [PATCH 1/2] libc: fix setting return value and errno in fallocate()

[Bernhard Reutner-Fischer]

On September 17, 2015 11:52:55 PM GMT+02:00, Rich Felker <dal...@libc.org> 
wrote:
>On Thu, Sep 17, 2015 at 09:27:40PM +0200, Bernhard Reutner-Fischer
>wrote:
>> On September 17, 2015 6:16:48 PM GMT+02:00, Yuriy Kolerov
><yuriy.kole...@synopsys.com> wrote:
>> >Hi Rich.
>> >
>> >fallocate must return 0 or -1. However posix_fallocate my return an
>> >error code. So I think it would be better to allow posix_fallocate
>> >change errno as fallocate does it and fix posix_fallocate return
>value
>> >according to POSIX.
>> 
>> fallocate () should be implemented on top of posix_fallocate, yes.
>
>I don't think this is possible. fallocate has an extra mode argument
>which posix_fallocate lacks.

Right, didn't remember the mode arg.

Thanks,

___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [PATCH 0/3] ARC uClibc fixes

[Bernhard Reutner-Fischer]

On December 14, 2015 7:09:40 AM GMT+01:00, Vineet Gupta 
 wrote:
>On Wednesday 21 October 2015 12:42 PM, Vineet Gupta wrote:
>> Hi,
>> 
>> Assorted fixes for ARC, please consider applying.
>> 
>> Thx,
>> -Vineet
>
>Ping !

Sorry for the long delay, will push these during christmas break.

Thanks,
>
>Or should we assume that uClibc is dead for good !
>
>-Vineet
>
>> 
>> Vineet Gupta (3):
>>   NPTL/ARCv2: Implement full memory barrier for NPTL
>>   NPTL/ARC: fix __lll_lock_wait_private redefinition for static links
>>   ARC: With NPTL support, GP is no longer used for PIC
>> 
>>  ldso/ldso/arc/dl-sysdep.h  | 6
>--
>>  libc/sysdeps/linux/arc/bits/atomic.h   | 7
>+--
>>  libpthread/nptl/sysdeps/unix/sysv/linux/arc/lowlevellock.c | 4 +++-
>>  3 files changed, 8 insertions(+), 9 deletions(-)
>> 
>
>___
>uClibc mailing list
>uClibc@uclibc.org
>http://lists.busybox.net/mailman/listinfo/uclibc


___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [PATCH] uClibc++: any throw statement causes memory corruption

[Bernhard Reutner-Fischer]

On March 12, 2016 12:18:02 AM GMT+01:00, Ivan Koldaev <pixus...@gmail.com> 
wrote:
>On Fri, Mar 11, 2016 at 1:41 PM, Rob Landley <r...@landley.net> wrote:
>> On 03/04/2016 01:48 PM, Ivan Koldaev wrote:
>>> Patch for uClibc++ bug #8741
>(https://bugs.busybox.net/show_bug.cgi?id=8741)
>>>
>>> I have discovered that uClibc++ incorrectly implements C++ exception
>>> ABI, allocating not enough memory in the
>>> "__cxxabiv1::__cxa_allocate_exception":
>>
>> When I spoke to Garrett Kajmowicz on the phone last month, he said
>that
>> his previous day job stuck with last GPLv2 release of gcc, so he
>stopped
>> staying up to date with changes in the C++ specification after ~2007.
>> Meaning he hasn't touched uClibc++ in years.
>>
>> He switched jobs recently (at Google now) but didn't seem
>particularly
>> interested in picking up where he left off after a multi-year gap. (I
>> think they use LLVM internally there, and thus
>http://libcxx.llvm.org/ ?
>> I know Android and ChromeOS do, dunno about the web server plumbing
>> stuff he's dealing with. It sounded more like AI research than
>anything
>> else, really...)
>>
>> I still use it in Aboriginal Linux, but only because I haven't
>switched
>> my toolchain to LLVM yet...
>>
>> Rob
>
>Rob,
>
>I appreciate your input.
>I understand that original author stepped away from the uClibc++
>development,
>but as I understand uClibc++ is not completely abandoned project,
>since there are still commits dated 6 days ago
>(https://git.uclibc.org/uClibc++/log/) by Bernhard Reutner-Fischer.
>Also OpenWRT uses uClibc++ as a primary C++ library with the latest
>GCC 5.2.x (luckily almost no program is using exceptions on embedded).
>So if you are saying that posting to this list is not a right way to
>have my patch accepted, could you please point me to the right one.
>Thank you for your time.
>
>P.S. added Bernhard Reutner-Fischer into CC, because I hope for some
>movement for this patch.

I have this scheduled, thanks. Will push together with a second patch as soon 
as I have written a trivial testcase for the second buglet.

Thanks for the patch!
Cheers,


___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [PATCH 0/2] ARC Moving to @pcl relocations

[Bernhard Reutner-Fischer]

On July 28, 2016 8:50:41 PM GMT+02:00, Vineet Gupta 
 wrote:
>Hi Andrew,
>
>On 07/28/2016 11:20 AM, Andrew Burgess wrote:
>> This is a slightly odd series of 2 patches.  The two patches are
>> actually alternative solutions to the same problem.  I'm keen to see
>> one of these merged, but I don't know which method would be
>preferred.
>>
>> This commit aims to address an issue that was introduced / mentioned
>> in commit 20554a78a9bba278c6b9cbbb4cfc5bde3772c56d (ARC:
>> Conditionalise certain relocations as provided by TLS tools only).
>>
>> The problem is that not all historic versions of binutils have
>> supported the @pcl relocation type.  This problem is compounded by
>the
>> fact that the arithmetic construct that was previously used to
>> synthesise an @pcl like behaviour, does not work on recent versions
>of
>> binutils.
>>
>> In the commit 20554a78a code was added that selects between the new
>> style @pcl relocations, and the old style arithmetic construct,
>> however, this selection is done based on whether the uClibc user has
>> configured with native threads or not.
>
>Right - the idea at the time was @pcl was added to tools for TLS/NPTL
>support and
>thus uClibc NPTL loosely implied that your tools will have that support
>- but this
>was not the ideal choice I agree.
>
>> Of course, a uClibc user could choose to use a modern version of
>> binutils AND configure without native thread support, in which case
>> uClibc will not compile.
>>
>> I have two proposed solutions.  In patch 1/2 I simply drop support
>for
>> the older versions of binutils in favour of the new @pcl relocation
>> type.  This feels the cleanest solution, but I don't know how
>strongly
>> the uClibc(-ng) community feels about maintaining compatibility for
>> older versions of the tools.
>
>So this was reported recently by Waldemar's build service too.
>
>http://mailman.uclibc-ng.org/pipermail/devel/2016-July/001072.html
>
>And we have an exact same patch floated internally which Vlad sent out
>earlier
>this week
>
>> Given that I anticipated push back against the first patch I took a
>> look at how I might maintain compatibility.
>
>Not really - while indeed 1/2 opens up a non-compatibilty window, there
>is less
>likelihood people will mix-n-match different baselines of uclibc and
>gcc/gas. So
>Vlad's patch does exactly that.
>
>> It turns out to be pretty
>> easy, and that is patch 2/2.  In this patch I drew inspiration from
>> similar examples in the Rules.mak file to check if the toolchain
>> supports @pcl relocations or not.  With this done we have a new
>define
>> based on the specific toolchain feature being supported or not, which
>> can then be used to conditionalise the code.
>
>Indeed your 2/2 seems to be the most "past-proof" code change. So I
>would think it
>is indeed better and is something I should have done in the first
>place.
>
>@Alexey, @Vlad what say you ?

uClibc traditionally supports the current stable release of binutils, which 
would make it patch #1 I think.

Thanks,
>
>-Vineet
>
>> Would you consider merging one of these patches?
>>
>> Thanks,
>> Andrew

___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: C++ iostream problem in uClibc++ library

[Bernhard Reutner-Fischer]

On August 3, 2016 8:02:29 AM GMT+02:00, Vikram Singh  wrote:
>Hi all
>
>I am porting uClibc++ library for a standalone os-less barecoard. The
>uClibc C library is working fine. But uClibc++ std::cin & std::cout are
>not
>working. Almost all other C++ features are working like class, new &
>delete, ctor & dtor, exception handling etc.
>
>While other features are working BUT cin & cout are not working. What
>the
>problem may be?

You need to be more specific. What does not work? Testcase including 
instructions on how to build it, what architecture, what toolchain...

Thanks,

___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [PATCH] stream: Add support for 64-bit integers

[Bernhard Reutner-Fischer]

On Tue, 2 Apr 2019 at 06:07, Rosen Penev  wrote:
>
> Many programs like gptfdisk or powertop try to use 64-bit integers with
> streams. This adds support for them.

I had to tweak the test a bit and also had to adjust the expected test-output.
make check
resp, for a diff:
make check V=1

Applied with these minor edits, thanks!
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [PATCH] buildsys: Preserve arguments passed on

[Bernhard Reutner-Fischer]

On Fri, 22 Mar 2019 at 03:36, Joseph Benden  wrote:
>
> This patch ensures all arguments are quoted, during command-line
> construction.
>
> This fixes compilation where spaces occur within the arguments.

Can you give me an example please?
g++-uc -DFOO="BAR BAZ" -c ... ?

TIA,
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [PATCH] buildsys: Preserve arguments passed on

[Bernhard Reutner-Fischer]

On Thu, 4 Apr 2019 09:41:52 -0700
Joseph Benden  wrote:

> On 4/4/19 8:04 AM, Bernhard Reutner-Fischer wrote:
> > On Fri, 22 Mar 2019 at 03:36, Joseph Benden  wrote:  
> >> This patch ensures all arguments are quoted, during command-line
> >> construction.
> >>
> >> This fixes compilation where spaces occur within the arguments.  
> > Can you give me an example please?
> > g++-uc -DFOO="BAR BAZ" -c ... ?
> >
> > TIA,
> >  
> Hi,
> 
> Yes.

I think we can simply avoid the whole issue.
May i ask you to try the attached patch instead?
TIA,
diff --git a/bin/Makefile.in b/bin/Makefile.in
index 8d11316..9ea2f06 100644
--- a/bin/Makefile.in
+++ b/bin/Makefile.in
@@ -32,26 +32,20 @@ define do_wrapper
 	$(Q)echo 'WRAPPER_LIBS="$(strip $(LIBS))"' >> $@.tmp
 	$(Q)echo '' >> $@.tmp
 	$(Q)echo 'WRAPPER_INCLIB="Y"' >> $@.tmp
-	$(Q)echo 'while [ -n "$$1" ]' >> $@.tmp
+	$(Q)echo 'for arg' >> $@.tmp
 	$(Q)echo 'do' >> $@.tmp
-	$(Q)echo '	WRAPPER_OPTIONS="$$WRAPPER_OPTIONS $$1"' >> $@.tmp
-	$(Q)echo '	if [ "$$1" = "-c" -o "$$1" = "-E" -o "$$1" = "-S" ]' >> $@.tmp
-	$(Q)echo '	then' >> $@.tmp
-	$(Q)echo '		WRAPPER_INCLIB="N"' >> $@.tmp
-	$(Q)echo '	fi' >> $@.tmp
-	$(Q)echo '	if [ "$$1" = "-static" -a "$$WRAPPER_LIBS" != "$(strip $(STATIC_LIBS))" ]' >> $@.tmp
-	$(Q)echo '	then' >> $@.tmp
-	$(Q)echo '		WRAPPER_LIBS="$(strip $(STATIC_LIBS))"' >> $@.tmp
-	$(Q)echo '	fi' >> $@.tmp
-	$(Q)echo '	shift' >> $@.tmp
+	$(Q)echo '	case "$$arg" in' >> $@.tmp
+	$(Q)echo '	-c|-E|-S) WRAPPER_INCLIB="N" ;;' >> $@.tmp
+	$(Q)echo '	-static) [ "$$WRAPPER_LIBS" != "$(strip $(STATIC_LIBS))" ] && WRAPPER_LIBS="$(strip $(STATIC_LIBS))" ;;' >> $@.tmp
+	$(Q)echo '	esac' >> $@.tmp
 	$(Q)echo 'done' >> $@.tmp
 	$(Q)echo 'if [ "$$WRAPPER_INCLIB" = "Y" ]' >> $@.tmp
 	$(Q)echo 'then' >> $@.tmp
 	$(Q)echo '	WRAPPER_OPTIONS="$$WRAPPER_OPTIONS -nodefaultlibs $$WRAPPER_LIBDIR -l$(LNAME) $$WRAPPER_LIBS"' >> $@.tmp
 	$(Q)echo 'fi' >> $@.tmp
 	$(Q)echo '' >> $@.tmp
-	$(Q)echo '[ -n "$$V" ] && [ $$V -gt 1 ] && echo $(CXX) $(GEN_CFLAGS) $(GEN_CXXFLAGS) $(EH_CXXFLAGS) $$WRAPPER_INCLUDEDIR $$WRAPPER_OPTIONS' >> $@.tmp
-	$(Q)echo 'exec $(CXX) $(GEN_CFLAGS) $(GEN_CXXFLAGS) $(EH_CXXFLAGS) $$WRAPPER_INCLUDEDIR $$WRAPPER_OPTIONS' >> $@.tmp
+	$(Q)echo '[ -n "$$V" ] && [ $$V -gt 1 ] && echo $(CXX) $(GEN_CFLAGS) $(GEN_CXXFLAGS) $(EH_CXXFLAGS) $$WRAPPER_INCLUDEDIR "$$@" $$WRAPPER_OPTIONS' >> $@.tmp
+	$(Q)echo 'exec $(CXX) $(GEN_CFLAGS) $(GEN_CXXFLAGS) $(EH_CXXFLAGS) $$WRAPPER_INCLUDEDIR "$$@" $$WRAPPER_OPTIONS' >> $@.tmp
 	$(Q)echo '' >> $@.tmp
 	$(Q)chmod 0755 $@.tmp
 	$(Q)mv $@.tmp $@
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

[ANNOUNCE] uClibc++-0.2.5 released

[Bernhard Reutner-Fischer]

Hi!

The uClibc team is happy to announce the release of uClibc++-0.2.5.

Many thanks to everyone who sent feedback, reported bugs, helped
testing patches or submitted patches!

The meta-changelog (see ChangeLog in the release tarball):

-   wrapper: Fix handling arguments with spaces
-   stream: Add support for 64-bit integers
-   buildsys: allow to pass in LDFLAGS
-   __base_associative: fix erase(iter,iter), e.g. multimap
-   list: fix splice to empty list from other.begin()
-   add refcounted exceptions
-   tests: Allow to run tests via a simulator
-   algorithm: Fix decl of stable_sort
-   string: assign(): fix two bugs
-   C++14 sized allocation
-   buildsys: Revamp. Fix spurious rebuilds, check CXXFLAGS with CXX
-   iostream: fix string getline to set noskipws
-   istream: add missing operator >> implementation
-   buildsys: rename .config WARNINGS to UCLIBCXX_WARNINGS
-   unwind: Fix for __ARM_EABI_UNWINDER__

The full ChangeLog can be found here:
https://cxx.uclibc.org/src/ChangeLog-0.2.4_0.2.5

For a list of available tarballs see:
https://cxx.uclibc.org/download
E.g.:
https://cxx.uclibc.org/src/uClibc++-0.2.5.tar.xz

Please report bugs in the uClibc++ project of https://bugs.uclibc.org after 
having read
https://uclibc.org/developing.html#contrib

Have fun!
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: Timezone not parsed correctly for Israel standard time

[Bernhard Reutner-Fischer]

On Sun, 3 Feb 2019 18:54:35 +0200
Tsvi Mostovicz  wrote:

>  Hi all,
> 
> I'm unaware whether this has been fixed or if it is a real bug, but I think
> the issue is with uclibc (I thought it would be busybox, but they don't
> seem to care about timezones).
> It seems that uclibc has an issue parsing /etc/TZ file correctly for Israel
> Standard Time.
> 
> According to GNU's explanation of /etc/TZ:
> 
> "Israel Standard Time (IST) and Israel Daylight Time (IDT) are 2 hours
> ahead of the prime meridian in winter, springing forward an hour on March’s
> fourth Thursday at 26:00 (i.e., 02:00 on the first Friday on or after March
> 23), and falling back on October’s last Sunday at 02:00.
> 
> IST-2IDT,M3.4.4/26,M10.5.0"
> 
> But it seems that uclibc has trouble understanding the value of 26.
> When I set /etc/TZ as below:
> 
> echo "IST-2IDT,M3.4.4/26,M10.5.0" > /etc/TZ
> 
> and run the date command, I get the UTC time. If I change the 26 to a
> value less than 24 I get the correct time in IST/IDT.
> 
> The following report
> https://dev.archive.openwrt.org/ticket/11445.html#comment:11 seems
> related to the issue.
> 
> I have no problem creating a patch, but I couldn't find where the date
> command get's the info from the /etc/TZ file.

the TZ handling is in
libc/misc/time/time.c
tests live in test/time/
and you probably want to extend test/time/tst-posixtz.c

HTH,
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [PATCH] istream_helpers: Fix sscanf typo

[Bernhard Reutner-Fischer]

On 8 October 2019 00:57:32 CEST, Rosen Penev  wrote:
>This caused readin not to work properly with long long types.

Please add a testcase too.
TIA,
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc