nds broken by recent patches

[Jeff Law]

On 1/28/2022 7:12 PM, Stafford Horne wrote:
> On Fri, Jan 28, 2022 at 05:58:46PM -0700, Jeff Law wrote:
>>
>> On 1/28/2022 4:32 PM, Stafford Horne wrote:
>>> On Fri, Jan 28, 2022 at 02:54:24PM -0700, Jeff Law wrote:
>>>> Replying to myself...
>>>>
>>>> On 1/28/2022 9:36 AM, Jeff Law wrote:
>>>>> For example, someone mucked up the compiler for or1k-elf at the same
>>>>> time you're doing your refactoring.  Now I've got a patch to fix the
>>>>> compiler ICE, *but* I'm also getting a crap-ton of new testsuite
>>>>> failures in the testsuite due to missing _init/_fini symbols.  I don't
>>>>> know yet if that's a newlib issue or something else mucked up on the
>>>>> compiler side.
>>>> I think I've tracked this done.  The change to internalize
>>>> HAVE_INITFINI_ARRAY wasn't complete.  It missed newlib.  Affects aarch64,
>>>> arm, or1k and cris -elf ports.  I don't test for former pair, but I do test
>>>> the latter pair.   or1k and cris fail differently. or1k-elf code fails to
>>>> link, while cris-elf fails a few tests that rely on ctor/dtor support.
>>> Is there anything I can help with here for or1k-elf?  Or was this something I
>>> did wrong with ff7b7b894 ("libgloss: or1k: If available call the init for
>>> init_array")?
>> It's a trivial goof in some recent refactoring in newlib.
>>
>>> I haven't rebuilt my newlib toolchain since last year or so.
>> Which raises an interesting set of questions.  Is or1k at a point where we
>> can cross build glibc & the kernel using upstream bits?    Is qemu user mode
>> emulation available?  The former pair would be a step forward from a testing
>> standpoint.  If we had the latter too, then we could build a rootfs and do
>> native 3-stage testing in a chroot.
> Now that glibc is upstream I guess the answer is yes.
>
> I have been building a buildroot using my glibc braches/now on master (maybe
> some buildroot patches need to be upstreamed to tell buildroot or1k has glibc
> support).
I don't use the builtroot project to construct mine.  Though perhaps I 
should ;-)

>
> With that we can test using qemu user mode.  I used to use qemu user mode to test
> the glibc test-suite but not all syscalls are emulated so there were some tests
> that would fail.
Yea, I'm much more concerned about testing GCC and 3-staging using qemu 
user mode & running the testsuite does a much more thorough job than 
just building newlib and running the gcc testsuite.

Thanks.  Clearly I've got a little project on the horizon.

jeff