[uclibc-ng-devel] Release announcements

2020-12-02 Thread Ata, John (US) 
Hi,

I seem to recall in the past that new uclibc-ng releases would be announced in 
this group.  The last two release announcements (1.0.35 and 1.0.36) do not 
appear in my feed.  Perhaps my mail server discarded them but I wonder if we 
are still announcing them to the group or are we counting on people manually 
checking the website?

Take care,

John Ata, CISSP
Senior Principal Software Engineer
Electronics Systems
STOP Operating System Software 
Development

T 703-563-8115 | F 703-668-4359 | 
john@baesystems.com
http://www.baesystems.com/csp

[cid:image001.png@01D138BC.8E54E330][cid:image003.png@01D138BC.8E54E330][cid:image004.png@01D138BC.8E54E330][cid:image006.png@01D138BC.8E54E330]


___
devel mailing list
devel@uclibc-ng.org
https://mailman.uclibc-ng.org/cgi-bin/mailman/listinfo/devel

Re: [uclibc-ng-devel] uclibc with gcc 8.3.1

2020-02-27 Thread Ata, John (US) 
Hi Waldemar,

Thanks for your reply. I believe RHEL/Centos 8 now uses gcc 8.3.1 
(https://centos.pkgs.org/8/centos-appstream-x86_64/gcc-8.3.1-4.5.el8.x86_64.rpm.html).
  However, I'm glad that 8.3.0 has been used successfully with uClibc-ng.  I'm 
having the usual porting problems (x86_64, 64 bit and 32 bit) upgrading from 
gcc 4.8.5).  So far, the biggest problem I'm having is with the sanitizer since 
the data structures from uClibc can be slightly different than glibc causing 
problems. Did you turn the sanitizer off in your build? Are there are buildroot 
patches for gcc 8.3 specific to uClibc that I might have missed?

Take care,
 
John Ata, CISSP
Senior Principal Software Engineer
Electronics Systems
STOP Operating System Software Development

T 703-563-8115 | F 703-668-4359 | john@baesystems.com
http://www.baesystems.com/csp


-Original Message-
From: Waldemar Brodkorb  
Sent: Thursday, February 27, 2020 7:43 AM
To: Ata, John (US) 
Cc: devel@uclibc-ng.org
Subject: Re: [uclibc-ng-devel] uclibc with gcc 8.3.1

*** WARNING ***
EXTERNAL EMAIL -- This message originates from outside our organization.


Hi John,
Ata, John  (US) wrote,

> Hi all,
> 
>  
> 
> Has anyone successfully created a toolchain with the latest uClibc and gcc
> 8.3.1?

What issues do you have?
gcc 8.3.0 is the latest release and I see no problems with it.

best regards
 Waldemar
___
devel mailing list
devel@uclibc-ng.org
https://mailman.uclibc-ng.org/cgi-bin/mailman/listinfo/devel

[uclibc-ng-devel] uclibc with gcc 8.3.1

2020-02-21 Thread Ata, John (US) 
Hi all,

Has anyone successfully created a toolchain with the latest uClibc and gcc 
8.3.1?

Thanks,

John Ata, CISSP
Senior Principal Software Engineer
Electronics Systems
STOP Operating System Software 
Development

T 703-563-8115 | F 703-668-4359 | 
john@baesystems.com
http://www.baesystems.com/csp

[cid:image001.png@01D138BC.8E54E330][cid:image003.png@01D138BC.8E54E330][cid:image004.png@01D138BC.8E54E330][cid:image006.png@01D138BC.8E54E330]


___
devel mailing list
devel@uclibc-ng.org
https://mailman.uclibc-ng.org/cgi-bin/mailman/listinfo/devel

[uclibc-ng-devel] getenv() bug

2019-11-14 Thread Ata, John (US) 
Hi,

The getenv() library call can trap under certain conditions.  It compares the 
passed in environment variable name (var) with the name=variables (*ep) in the 
environment area and returns a pointer to the value in the environment if it 
exists.  To accomplish this, it does a memcmp() using the length of the passed 
in name (len) for each environment variable (*ep) against the passed in name 
(var).  So memcmp will attempt to scan both strings for len bytes. However, if 
for some reason, len is equal to or greater than 16 and  longer than the length 
of  the *ep in the environment and the *ep resides near the end of a page 
boundary while the next page is not present or mapped, the memcmp could trap 
with a sigsegv error while continuing the scan with the optimization 
read-ahead. However, if strncmp is used instead, there is no problem since both 
source and destination scanning will stop when either reaches a terminating NULL

Test case: We are using gcc 4.8.5 and uclibc 1.0.31. With a small environment 
area, attempt to do a getenv() using a variable name such as 
"1234567890123456". Example: file run.c contains:

#include 
#include 

int main()
{
   char *n;

n = getenv("1234567890123456");
printf("Return val: \"%s\"\n", n);
return 0;
}

Then

 cc run.c -o run
 env -i 123=123 ./run.
Segmentation fault

Proposed fix:

--- uclibc/libc/stdlib/getenv.c  2019-11-13 17:22:26.260187664 -0500
+++ uclibc/libc/stdlib/getenv.c  2019-11-13 17:22:39.376111771 -0500
@@ -20,7 +20,7 @@
return NULL;
 len = strlen(var);
 while(*ep) {
-   if (memcmp(var, *ep, len) == 0 && (*ep)[len] == '=') {
+   if (strncmp(var, *ep, len) == 0 && (*ep)[len] == '=') {
return *ep + len + 1;
}
ep++;


Then

 env -i 123=123 ./run.


Can we get this patch upstream?

Thanks,

John Ata, CISSP
Senior Principal Software Engineer
Electronics Systems
STOP Operating System Software 
Development

T 703-563-8115 | F 703-668-4359 | 
john@baesystems.com
http://www.baesystems.com/csp

[cid:image001.png@01D138BC.8E54E330][cid:image003.png@01D138BC.8E54E330][cid:image004.png@01D138BC.8E54E330][cid:image006.png@01D138BC.8E54E330]

___
devel mailing list
devel@uclibc-ng.org
https://mailman.uclibc-ng.org/cgi-bin/mailman/listinfo/devel

Re: [uclibc-ng-devel] new release 1.0.32

2019-10-16 Thread Ata, John (US) 
Hi,

Good to see the new release... hope the word "still" is not ominous though... 
feel free to communicate any future thoughts!

Take care,
 
John Ata, CISSP
Senior Principal Software Engineer
Electronics Systems
STOP Operating System Software Development

T 703-563-8115 | F 703-668-4359 | john@baesystems.com
http://www.baesystems.com/csp


-Original Message-
From: devel  On Behalf Of Waldemar Brodkorb
Sent: Wednesday, October 16, 2019 10:46 AM
To: devel@uclibc-ng.org
Subject: [uclibc-ng-devel] new release 1.0.32

*** WARNING ***
EXTERNAL EMAIL -- This message originates from outside our organization.


Hi,

it is been a while, but the project is still not dead ;)
We have a new release, feel free to update.

best regards
 Waldemar

___
devel mailing list
devel@uclibc-ng.org
https://mailman.uclibc-ng.org/cgi-bin/mailman/listinfo/devel
___
devel mailing list
devel@uclibc-ng.org
https://mailman.uclibc-ng.org/cgi-bin/mailman/listinfo/devel

Re: [uclibc-ng-devel] use safe, even if possibly a few cycles slower, six-argument syscall implementation

2018-12-06 Thread Ata, John (US) 
On January 29,2017 a patch 
(9b457baf8d46329f7d7ee2aa084022bb0df88551)by
 mirabilos m...@mirbsd.org was accepted in the 
repository.  I have a few questions on this patch.


1)  The patch created a new file syscall6.S in the i386 directory.   It 
seems functionally equivalent to the syscall.S.  Both process 6 arguments plus 
the NR.  Both use the exact same registers.   Only an alignment directive has 
been added and the order of loading the registers is reverse.  It also appears 
that glib does not have a special syscall6.S.  Why did we go this route special 
casing 6 argument syscalls only?

2)  The LOADARGS_6, RESTOREARGS_6 and ASMFMT_6 defines are removed from 
.  It is not clear why from the patch.

3)  There seems to be a deficiency in the syscall setup that is not present 
in glibc making it impossible to get a backtrace from a syscall.  For example, 
If one looks at uclibs-ng's sysdeps.h in i386, one can see 
cfi_adjust_cfa_offset/cfi_rel_offset usage in the _PUSH_ARGS_1 and _POP_ARGS_N 
macros allowing backtrace information to be present on the stack.  However, 
syscall/syscall6.S as well as bits/syscalls.h do not allow for this. In 
addition, it appears that glibc does have this mechanism in its syscall.S.

Thoughts anyone?

Thanks,

John Ata, CISSP
Senior Principal Software Engineer
Electronics Systems
STOP Operating System Software 
Development

T 703-563-8115 | F 703-668-4359 | 
john@baesystems.com
http://www.baesystems.com/csp

[cid:image001.png@01D138BC.8E54E330][cid:image003.png@01D138BC.8E54E330][cid:image004.png@01D138BC.8E54E330][cid:image006.png@01D138BC.8E54E330]


___
devel mailing list
devel@uclibc-ng.org
https://mailman.uclibc-ng.org/cgi-bin/mailman/listinfo/devel

[uclibc-ng-devel] PATCH] Fix ntfw when called with FTW_CHDIR and FTW_DEPTH to change directory back to the parent before processing the directory (after the contents have already been processed).

2016-10-17 Thread Ata, John (US) 
Hi all,

In using ftw/nftw, I've discovered a bug when using FTW_CHDIR and FTW_DEPTH.  
After changing the working directory to a subdirectory, nftw would process the 
contents fine.  However, it would then try and process the directory itself 
while still in that directory and then switch back to the parent.  This would 
result in an error (ENOENT).  This patch will change working directories to the 
parent before processing the directory itself.

Take care,

John Ata, CISSP
Senior Principal Software Engineer
Electronics Systems
STOP Operating 
System
 Software Development

T 703-563-8115 | F 703-668-4359 | 
john@baesystems.com
http://www.baesystems.com/csp

[cid:image001.png@01D138BC.8E54E330][cid:image003.png@01D138BC.8E54E330][cid:image004.png@01D138BC.8E54E330][cid:image006.png@01D138BC.8E54E330]



0001-Fix-ntfw-when-called-with-FTW_CHDIR-and-FTW_DEPTH-to.patch
Description: 0001-Fix-ntfw-when-called-with-FTW_CHDIR-and-FTW_DEPTH-to.patch
___
devel mailing list
devel@uclibc-ng.org
http://mailman.uclibc-ng.org/cgi-bin/mailman/listinfo/devel