On 6/19/19 3:29 AM, Claudiu Zissulescu wrote: > Hi Jeff, > >> OK. >> > Thank you for your review. > >> THe BZ mentions that this was found building a glibc test for ARC. >> Is there a glibc port for the ARC? I don't see one in the glibc >> git repo. Are you aware of any plans to produce an official glibc >> port. > > Indeed, we are in the process of upstreaming the glibc port for arc. > However, we hit a number of issues, one being this BZ, and other is > the need to provide some ARC processor internals documentation. Once > those items cleaned up, the arc glibc port will be public available > upstream. That'll be great. It looks like there's an ARC kernel port (needed for the headers and kernel build step). So it should look like a standard cross glibc/kernel as far as my tester is concerned.
> >> >> I believe building glibc is a hell of a better sniff test than >> building newlib. So if it's in the plan, I'd love to re-wire my >> tester to test with glibc rather than newlib on the ARC port. >> > > I totally agree, we also have an uClibc-ng port which, as far as I > know, is fully upstream. If I may ask, how do you test the ARC > toolchain, do you use Synopsys free nSIM simulator? I've pondered wiring in support for uClibc, but haven't had the time. Right now for ARC we build libgcc, and newlib/libgloss, then run the gcc testsuite with a dummy simulator. Essentially this verifies the compiler generates code that can be assembled and linked and allows us to also use the tests which scan dumps. The dummy simulator always returns success to avoid useless noise. The state of simulated targets using newlib/libgloss is generally poor. A large part of the problem is the fixed, limited, memory size that's baked into the libgloss linker scripts. This results in numerous clashes of the heap & stack and whether or not those cause an execution failure is horribly unpredictable, so except for a couple ports I audited, I'm not doing simulator testing for the newlib/libgloss targets. jeff
