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

Gordan Bobic gordan at bobich.net
Mon Dec 30 12:48:26 UTC 2013

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
>>>>>>> problems without alignment issues, or structs being packed too
>>>> close
>>>>>>> together causing false sharing again w/o alignment being
>>>>>>> If alignment problems cause performance issues, then we should
>>>>>>> with those performance problems.  If they don't, we shouldn't
>>>>>>> about them.
>>>>>>> Rich.
>>>>>>> ObHack: I once worked with an architecture [68k-based VME
>>>>>>> that not only faulted on unaligned access, but also on accesses
>>>>>> the
>>>>>>> wrong *size* (eg. using a short-sized read instruction instead of
>>>>>>> word-sized read instruction).  Dealing with that nonsense
>>>> a
>>>>>>> lot of compiler-specific massaging of code and some inline
>>>>>> ...
>>>>>> 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
>>>>> No, if your code takes the approach to cast the struct pointer into
>>>> byte stream, the struct pointer itself can be unaligned.
>>>> It won't fix all cases, but it will fix a large chunk of them -
>>>> enough of them to make fixing the remainder a tractable problem.
>>> It's already tractable, you're choosing not to engage with solving it
>>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
>>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?
>>>>> Your compiler can do nothing about that, you have to touch the
>>>> members using bytewise accessors to be compatible with SoCs that
>>>> 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
>>>> a
>>>>>> bodge, but since complete fix of the underlying problem isn't
>>>> 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
>>of the problem.

More information about the arm mailing list