Re: [uclibc-ng-devel] [PATCH 00/32] FDPIC ABI for ARM

Am 30.07.2018 um 15:50 schrieb Christophe Lyon <

> On Wed, 25 Jul 2018 at 07:20, Waldemar Brodkorb &lt;wbx(a)uclibc-ng.org&gt;

> > Hi, > > the toolchain tests are finished successfully, but the armv5 runtime

It looks like tests are looping with getty error messages, is that what

Not yet. How can I run embedded-test.sh twice with different uclibc-ng version? (the original one, and the one with my patches) Should I restart from a new directory?

> best regards > Waldemar > >> Am 20.07.2018 um 10:25 schrieb Waldemar Brodkorb &lt;wbx(a)uclibc-ng.org&gt;rg>: >> >> Hi, >> >> sorry for the confusion. >> I take care about the last failure. >> The build runs further so, I give you feedback once it is finished. >> >> I can squash the patch before pushing, >> >> best regards >> Waldemar >> >>>> Am 20.07.2018 um 10:06 schrieb Christophe Lyon <

>>>> >>>> On Thu, 19 Jul 2018 at 20:15, Waldemar Brodkorb &lt;wbx(a)uclibc-ng.org&gt;

>>>> >>>> Hi, >>>> >>>> okay, that was already the next test >>>> armv5-nommu-arm, which OpenADK needs to learn, as the default is

>>> I'm not sure to understand; if by "now" you mean with my uclibc-ng >>> patch series, then no. At least not yet. >>> As said in the cover letter this patch series supports only armv7. And >>> as noticed by Thomas, it doesn't yet support armv7m. >>> The plan is definitely to support armv7m. >>> >>> So you probably want to create a new config armv7-nommu-arm in your

>>> >>> Since I'm not familiar with this script nor openadk, I don't know what >>> this implies. >>> >>> I thought you wanted to first make sure my uclibc-ng patch series >>> didn't break existing configs. >>> >>> If you want to try fdpic mode, you'll need a recent GCC trunk + my GCC >>> patches (see link in cover letter). You also need recent binutils. I >>> don't know if/how your script handles that since I noticed "7.3.0" in >>> the GCC error messages you shared, which seems to indicate you are not >>> using the most recent GCC. >>> >>> And also note that the GCC/binutils target name is

>>> This will configure GCC is the right mode, no need to use flags such

>>> >>> >>>> Will you sent a complete patch with sob for the previous error? >>> Which previous error? If you mean the latest you reported involving >>> -mfdpic, then I hope my answer just above clarifies. >>> >>> If you mean the broken armv5 build, then yes, but the patch I sent >>> recently only needs to be squashed with patch 4/32 "rtld: Add FDPIC >>> code for arm" >>> >>> What the practice on this list? Shall I send v2 of patch 4/32 asap, on >>> rather wait for feedback on other patches and then send a v2 of the >>> whole series? >>> >>> Thanks, >>> >>> Christophe >>> >>> >>>> best regards >>>> >>>> Waldemar >>>> >>>>> Am 19.07.2018 um 18:31 schrieb Christophe Lyon <

>>>>> >>>>> On Thu, 19 Jul 2018 at 14:33, Waldemar Brodkorb >>>>> &lt;mail(a)waldemar-brodkorb.de&gt; wrote: >>>>>> >>>>>> Hi, >>>>>> Christophe Lyon wrote, >>>>>> >>>>>>>> On Wed, 18 Jul 2018 at 18:37, Waldemar Brodkorb <

>>>>>>>> >>>>>>>> Hi, >>>>>>>> Christophe Lyon wrote, >>>>>>>> >>>>>>>>>> On Wed, 18 Jul 2018 at 09:37, Waldemar Brodkorb <

>>>>>>>>>> >>>>>>>>>> Hi Christophe, >>>>>>>>>> Waldemar Brodkorb wrote, >>>>>>>>>> >>>>>>>>>>> Hi Christophe, >>>>>>>>>>> >>>>>>>>>>> i am doing a large testrun for the global changes and

>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ARM v5 soft eabi arm mode fails to compile, see the attached

>>>>>>>>>> log. You can check with embedded-test.sh if you like. >>>>>>>>>> >>>>>>>>>> Any idea? All patches appliend on top of master, >>>>>>>>> >>>>>>>>> Thanks for testing this configuration. >>>>>>>>> >>>>>>>>> I left FDPIC-only code activated unconditionally. >>>>>>>>> >>>>>>>>> Can you try the attached small patch? >>>>>>>> >>>>>>>> Even fixing this small typo in #endf it errors out. >>>>>>>> >>>>>>> OK, here is an updated version of the previous patch. >>>>>> >>>>>> Works for the ldso, but I think we need a symbol to differentiate >>>>>> between ELF and FDPIC. >>>>>> See attached error. >>>>> >>>>> Strange, the build succeeded for me. I don't understand where this >>>>> -mfdpic option comes from? >>>>> It is not part of the patches I sent, unless I'm mistaken: it would

>>>>> "embedded" in GCC if configured for FDPIC, which is not the case in >>>>> this build for armv5. >>>>> >>>>> >>>>>> >>>>>>>>> I have an embedded-test.sh build running now. Sorry, I didn't

>>>>>>>>> about this script, I have used armv5 as arch, is it the one you

>>>>>>>> >>>>>>>> somthing like this, uclibc-ng is a directory including all

>>>>>>>> mksh embedded-test.sh --libc=uclibc-ng --libc-source=uclibc-ng

>>>>>>> >>>>>>> Is there a way to avoid (re)creating all the source tarballs?