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@warmcat.com wrote:
Gordan Bobic gordan@bobich.net wrote:
On 12/30/2013 11:54 AM, Andy Green wrote:
Gordan Bobic gordan@bobich.net wrote:
On 12/30/2013 09:58 AM, Andy Green wrote:
Gordan Bobic gordan@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
-
Gordan Bobic