[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).

[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

Re: [uclibc-ng-devel] CONFIG_UCLIBC_SUSV2_LEGACY triggers odd SIGSEGV in busybox's ash on MIPS

[Joshua Kinard]

On 10/17/2016 14:54, Waldemar Brodkorb wrote:
> Hi Joshua,

[snip]

> 
> You don't like cross-compiling, right?
> uClibc-ng seems not only be interesting for embedded devices, but
> also for classic old unix hardware :)
>  

Oh, I cross-compile all the time.  All of my SGI kernels are built with
cross-compilers.  Userland cross-compiling has just generally been trickier
than kernel cross-compiles, so I don't use it as often.  Plus, testing on the
hardware itself can turn up some rather interesting bugs at times, and in other
instances, you sometimes need the hardware to investigate if a particular CPU
quirk will come back to haunt you (the R10K's speculative execution one being
an all-time classic example).

And yeah, classic hardware still has its place!  There's a port of the Linux
kernel to the IP35-class of SGI hardware (Origin 300, Fuel, Tezro), that's been
started, but hasn't had any recent updates.  But it is functional enough to
boot a netboot with, supposedly, so that's on my infinitely-long TODO list to
try out at some point.  These platforms are still quite plentiful on eBay,
oddly enough, although parts for IP27 machines are becoming pretty scarce,
especially the larger Origin 2000/Onyx2 rack setups.

[snip]

>  
>>> What are you running on the Octane? Linux 64 Bit or 32 Bit?
>>> (n32,o32,n64 in case of 64Bit)
>>
>> Octanes can only boot a 64-bit kernel (same as their IP27 cousins), due to
>> their firmware only supporting 64-bit ELF format.  All of my SGI's run
>> N32/glibc-based userlands, though when I format the O2, it'll be back to O32
>> until I figure out how good uclibc's N32 support is.  I've also got a 
>> multilib
>> chroot based on glibc that mixes O32, N32, and N64, but wasn't able to 
>> complete
>> a fresh stage build with it due to some really weird glibc bug that popped up
>> during the stage3 build cycle.  I have to get glibc-2.24 into play and give 
>> it
>> another go at some point.
> 
> I tested n32 support on my Lemote Yeelong, so you should at least be
> able to boot. A longer time ago I had Xorg and Firefox running on
> the book. Firefox only support n32. The Lemote has a page size of
> 16k, so it showed some interesting bugs in uClibc/uClibc-ng in the past.

I haven't tried running X11 stuff in a long time on these systems.  Octane has
an X11 driver for its Impact graphics board, but my last attempt to fix it up
to compile, plus integrate other fixes for it, resulted in a SIGSEGV that I
lacked knowledge on debugging correctly.  I mostly stick to command-line right
now on these platforms.  And the direction that the Linux ecosystem itself is
moving towards, e.g., Wayland, may throw GUI support into doubt in the future
(have never actually tried Wayland yet).  Way too many things with the hardware
that still need fixing before one can take a look at the shiny bits.

Have you tried 64K PAGE_SIZE by chance?  I use that setting on all of my SGI
systems except for the IP27, which has a peculiar Oops crop up under 64K, so
that machine boots 16K PAGE_SIZE at the moment.  You actually get a nice
performance bump on 16K or 64K versus the standard 4K.  The testing netboot
image I ran on my IP27 w/ 16K showed no ill effects, but I still need to do 64K
on the O2 and Octane.

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
6144R/F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And our
lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic
___
devel mailing list
devel@uclibc-ng.org
http://mailman.uclibc-ng.org/cgi-bin/mailman/listinfo/devel

Re: [uclibc-ng-devel] CONFIG_UCLIBC_SUSV2_LEGACY triggers odd SIGSEGV in busybox's ash on MIPS

[Waldemar Brodkorb]

Hi Joshua,
Joshua Kinard wrote,

> On 10/16/2016 17:45, Waldemar Brodkorb wrote:
> [snip]
> 
> > 
> > I have 2xO2 and 2xIndy.
> > 
> > The modern O2:
> >> hinv
> >System: IP32
> > Processor: 300 Mhz R5000, with FPU
> >  Primary I-cache size: 32 Kbytes
> >  Primary D-cache size: 32 Kbytes
> >  Secondary cache size: 1024 Kbytes
> >   Memory size: 128 Mbytes
> >  Graphics: CRM, Rev C
> > Audio: A3 version 1
> > SCSI Disk: scsi(0)disk(1)
> >SCSI CDROM: scsi(0)cdrom(4)
> > 
> 
> This is the one you'll want to use with Linux.  The 300MHz R5000's are 
> actually
> RM5261's by PMC Sierra (who bought them via their QED acquisition many years
> ago).  Linux refers to them as "Nevada" (CONFIG_CPU_NEVADA).  You can add up 
> to
> 1GB RAM, but when configuring the framebuffer (GBEFB) in the kernel, don't set
> its RAM higher than 4MB (else an Oops due to a *really* old bug no one's 
> chased
> down yet).

Thanks for the hints.
 
> I'm actually trying to get this netboot working so that I can re-install my O2
> w/ a uClibc-ng-based rootfs.  It's currently on an n32 glibc rootfs, but with
> gcc's increasingly-larger compile times and glibc's bloat, that machine,
> despite its 350MHz RM7000 CPU, just takes too long to do stuff (gcc is about a
> ~24-hour job).  64-bit PCI-X is also a little off, but 32-bit PCI should work
> fine as long as the driver isn't braindead and assumes little-endian.

You don't like cross-compiling, right?
uClibc-ng seems not only be interesting for embedded devices, but
also for classic old unix hardware :)
 
> > The classic O2:
> >> hinv
> >System: IP32
> > Processor: 175 Mhz R1, with FPU
> >  Primary I-cache size: 32 Kbytes
> >  Primary D-cache size: 32 Kbytes
> >  Secondary cache size: 1024 Kbytes
> >   Memory size: 128 Mbytes
> >  Graphics: CRM, Rev C
> > Audio: A3 version 1
> > SCSI Disk: scsi(0)disk(2)
> >SCSI CDROM: scsi(0)cdrom(4)
> > 
> > So I should bootup a system on the modern O2?
> > OpenBSD is running 64Bit kernel and userland on O2 and I think I
> > remember they fixed the r10k issues somehow.
> 
> Yeah, OpenBSD solved the R10K issues, I *think*, by padding the affected
> instructions out with tons of 'cache' instructions, which I think is one of 
> the
> stated solutions for dealing w/ R10K's speculative execution feature on the
> non-coherent platforms (I think at the cost of a significant performance hit).
> I was told once that Linux's memory design and TLB handling is too complicated
> for a similar approach, but I haven't tried looking into the issue at all
> lately.  R12K CPUs have a hardware bit in their config register called "Delay
> Speculative Dirty" (DSD) that's supposed to help mitigate the problem, but you
> apparently still have to add some cache barriers before loads or stores (or
> both?).  I recently picked one of those up, but haven't had a chance to try it
> out yet.

Thanks for your very detailed answer.
 
> > What are you running on the Octane? Linux 64 Bit or 32 Bit?
> > (n32,o32,n64 in case of 64Bit)
> 
> Octanes can only boot a 64-bit kernel (same as their IP27 cousins), due to
> their firmware only supporting 64-bit ELF format.  All of my SGI's run
> N32/glibc-based userlands, though when I format the O2, it'll be back to O32
> until I figure out how good uclibc's N32 support is.  I've also got a multilib
> chroot based on glibc that mixes O32, N32, and N64, but wasn't able to 
> complete
> a fresh stage build with it due to some really weird glibc bug that popped up
> during the stage3 build cycle.  I have to get glibc-2.24 into play and give it
> another go at some point.

I tested n32 support on my Lemote Yeelong, so you should at least be
able to boot. A longer time ago I had Xorg and Firefox running on
the book. Firefox only support n32. The Lemote has a page size of
16k, so it showed some interesting bugs in uClibc/uClibc-ng in the past.

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

[uclibc-ng-devel] uClibc-ng test suite

[Waldemar Brodkorb]

Hi Hackers,

I had a nice talk about uClibc-ng with Alexey on ELCE2016.
One of the points where the separation of the test suite included in
uClibc-ng source tree.

Recently Max and I discovered a problem regarding
libgcc/pthread_cancel, because the code was _not_ compiled with
the normal full shared gcc toolchain.
Every application gets compiled and linked with full toolchain, only
the test suite not.

I think this is wrong and I would like to remove the test-suite from
uClibc-ng source and want to create a separate project out of it.
Like musl hackers are doing it with their libc-test.

Furthermore I would like to synchronize the tests with GNU libc and
take a look that no internal uClibc stuff is used or only when
requested by the developer. So test suite could be run on GNU libc,
musl and uClibc-ng based system.

I would use libc-test, but they depend on GNU make and I want to be
able to run the test suite on noMMU targets.
@Szabolcs: Or are you interested in some joined efforts?

And furthermore I like the small summary to get a fast feedback
about any regressions before a release.

Recently Ignacy discovered the same issue while trying to rework
the internal unwind functions in uClibc-ng.

Any opinions? Any suggestions for the name of the test suite?

Plan is to do a release in the next days and afterwards separate the
test suite code before the next release.

Thanks,
 Waldemar
___
devel mailing list
devel@uclibc-ng.org
http://mailman.uclibc-ng.org/cgi-bin/mailman/listinfo/devel

Re: [uclibc-ng-devel] [RFC PATCH v4 1/1] libpthread: Fix inclusion of unwind code.

[Ignacy Gawędzki]

On Mon, Oct 17, 2016 at 03:40:04PM +0200, thus spake Ignacy Gawedzki:
> On Sun, Oct 16, 2016 at 10:01:30PM +0200, thus spake Waldemar Brodkorb:
> > > As I said, I used d4d4f37 and not strictly origin/master.  But I
> > > otherwise used the command line you gave me, including --libc-source.
> > 
> > But 17ad14e5780533db90171e16b95dbeda4e81ffb0 contains a workaround
> > for exactly the seen problem.
> >  
> > > I will re-run the tests with origin/master and my patch on top of it.
> 
> I found a few interesting things.  The test binaries are compiled by
> openadk with the "initial" GCC and not the "final" one.  The
> difference is that the implementation of the unwinder code is then
> taken from libgcc.a.  I get the same behavior if I explicitly add this
> library to the list of objects to link into the test binary.  With a
> final version of GCC, the implementation is taken from libgcc_s.so as
> it should and the behavior is maybe not ideal but to me it looks far
> better (is that because the initial GCC doesn't really implement any
> unwinder code?).

BTW, the initial GCC is built with --disable-threads.  Could that
possibly be the reason some of the tests in nptl fail?

-- 
Ignacy Gawędzki
R Engineer
Green Communications
___
devel mailing list
devel@uclibc-ng.org
http://mailman.uclibc-ng.org/cgi-bin/mailman/listinfo/devel

Re: [uclibc-ng-devel] [RFC PATCH v4 1/1] libpthread: Fix inclusion of unwind code.

[Ignacy Gawędzki]

On Sun, Oct 16, 2016 at 10:01:30PM +0200, thus spake Waldemar Brodkorb:
> > As I said, I used d4d4f37 and not strictly origin/master.  But I
> > otherwise used the command line you gave me, including --libc-source.
> 
> But 17ad14e5780533db90171e16b95dbeda4e81ffb0 contains a workaround
> for exactly the seen problem.
>  
> > I will re-run the tests with origin/master and my patch on top of it.

I found a few interesting things.  The test binaries are compiled by
openadk with the "initial" GCC and not the "final" one.  The
difference is that the implementation of the unwinder code is then
taken from libgcc.a.  I get the same behavior if I explicitly add this
library to the list of objects to link into the test binary.  With a
final version of GCC, the implementation is taken from libgcc_s.so as
it should and the behavior is maybe not ideal but to me it looks far
better (is that because the initial GCC doesn't really implement any
unwinder code?).

The reason why this works without my patch is that the implementation
of the unwinder code is then linked dynamically from libc.so, which,
as I've said previously, is not supposed to be used by code from
outside the lib itself.

I haven't had time yet to look into openadk in order to understand why
it's not using the final GCC to build the tests.  Do you have any
idea?

-- 
Ignacy Gawędzki
R Engineer
Green Communications
___
devel mailing list
devel@uclibc-ng.org
http://mailman.uclibc-ng.org/cgi-bin/mailman/listinfo/devel