[fedora-arm] Fedora 20 for Raspberry Pi????

[Gordan Bobic]

I didn't exhaustively check them, but IIRC (this was not far from nearly two years ago, so don't hold me to it) core libraries were among the better behaved packages. I don't recall any in glibc, for example.

I'll revisit the issue over the next few weeks as I start on another distro rebuild.


Andy Green <andy at warmcat.com> wrote:

>
>
>Gordan Bobic <gordan at bobich.net> wrote:
>>On 12/30/2013 11:54 AM, Andy Green wrote:
>>>
>>>
>>> Gordan Bobic <gordan at bobich.net> wrote:
>>>> On 12/30/2013 09:58 AM, Andy Green wrote:
>>>>>
>>>>>
>>>>> Gordan Bobic <gordan at bobich.net> wrote:
>>>>>> On 12/27/2013 04:02 PM, Richard W.M. Jones wrote:
>>>>>>> On Fri, Dec 27, 2013 at 09:53:54AM +0000, Gordan Bobic wrote:
>>>>>>>> How is transparent alignment fixup going to give you back the
>>>>>>>> performance you lose from accesses straddling cache lines?
>>>>>>>
>>>>>>> You can have structs straddling cache lines and causing
>>performance
>>>>>>> problems without alignment issues, or structs being packed too
>>>> close
>>>>>>> together causing false sharing again w/o alignment being
>>involved.
>>>>>>>
>>>>>>> If alignment problems cause performance issues, then we should
>>deal
>>>>>>> with those performance problems.  If they don't, we shouldn't
>>worry
>>>>>>> about them.
>>>>>>>
>>>>>>> Rich.
>>>>>>>
>>>>>>> ObHack: I once worked with an architecture [68k-based VME
>>hardware]
>>>>>>> that not only faulted on unaligned access, but also on accesses
>>of
>>>>>> the
>>>>>>> wrong *size* (eg. using a short-sized read instruction instead of
>>a
>>>>>>> word-sized read instruction).  Dealing with that nonsense
>>involved
>>>> a
>>>>>>> lot of compiler-specific massaging of code and some inline
>>assembly
>>>>>> ...
>>>>>>
>>>>>> I'm very glad you mentioned compilers - this is in fact easily
>>>> fixable
>>>>>> at compiler level. Intel's ICC has an option to make all arrays
>>and
>>>>>
>>>>> No, if your code takes the approach to cast the struct pointer into
>>a
>>>> byte stream, the struct pointer itself can be unaligned.
>>>>
>>>> It won't fix all cases, but it will fix a large chunk of them -
>>perhaps
>>>>
>>>> enough of them to make fixing the remainder a tractable problem.
>>>
>>> It's already tractable, you're choosing not to engage with solving it
>>upstream.
>>
>>I'll enumerate the instances of this next time I'm doing a RedSleeve 
>>rebuild (might start this week when I resurrect my Koji farm of
>>armv5tel 
>>devices). Last time I checked the number of instances logged was in the
>>
>>hundreds - sufficiently high that I just gave up.
>
>Yeah but that's hundreds of instances of one bug in one package or one instance of a hundred bugs in different packages?  If it's in a library it might show up in a few different processes but still be one bug.
>
>If it's in glibc it might show up many times in one session different ways but still be one issue.
>
>Did you try catching the sigbus or whatever you're getting in gdb?
>
>-Andy
>
>>>>> Your compiler can do nothing about that, you have to touch the
>>>> members using bytewise accessors to be compatible with SoCs that
>>don't
>>>> fix up unaligned access properly.
>>>>>
>>>>>> structs always aligned to a boundary (up to 16 byte, IIRC). If GCC
>>>> were
>>>>>>
>>>>>> to implement such a feature the problem could be made to go away
>>>>>> without
>>>>>> actually addressing the underlying cause of the problem. It might
>>be
>>>> a
>>>>>> bodge, but since complete fix of the underlying problem isn't
>>going
>>>> to
>>>>>> happen anyway, a good bodge would be a lot better than doing
>>>> nothing.
>>>>>
>>>>> What's wrong with you sending patches to the upstream?
>>>>
>>>> Nothing apart from the amount of man-months it would take to
>>>
>>> Nonsense... a few years ago I made my own cross distro for an ARM9
>>device without hardware fixup, entirely from source tarballs, and there
>>were almost no alignment issues in the major projects.
>>
>>I did the same 18 months ago, and my experience was distinctly 
>>different. Thankfully, with the kernel-level alignment fixup at least 
>>building the distro was tractable.
>>
>>> I guess they will tend to start to increase since more people are
>>using newer ARM SoC which all have hardware fixup - but you are the
>>backpressure against that by providing patches for the real problems
>>you found... at least if you care about it, you should be.
>>
>>A fair point well made, but I don't think we entirely agree on the
>>scale 
>>of the problem.
>>
>>Gordan
>