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@xxxxxxxxxxx> wrote: > > >Gordan Bobic <gordan@xxxxxxxxxx> wrote: >>On 12/30/2013 11:54 AM, Andy Green wrote: >>> >>> >>> Gordan Bobic <gordan@xxxxxxxxxx> wrote: >>>> On 12/30/2013 09:58 AM, Andy Green wrote: >>>>> >>>>> >>>>> Gordan Bobic <gordan@xxxxxxxxxx> 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 > _______________________________________________ arm mailing list arm@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/arm
