Page MenuHomeFreeBSD

Optimize the handling of big/little endian determination.
Needs ReviewPublic

Authored by stevek on Apr 3 2024, 11:27 PM.
Tags
None
Referenced Files
Unknown Object (File)
Sat, Nov 30, 5:01 AM
Unknown Object (File)
Nov 7 2024, 10:14 PM
Unknown Object (File)
Nov 7 2024, 9:52 PM
Unknown Object (File)
Nov 7 2024, 7:44 PM
Unknown Object (File)
Oct 26 2024, 5:35 AM
Unknown Object (File)
Oct 26 2024, 5:32 AM
Unknown Object (File)
Oct 11 2024, 3:16 AM
Unknown Object (File)
Oct 9 2024, 7:53 PM
Subscribers

Details

Reviewers
emaste
imp
Summary

Add variables to contain lists of MACHINE_ARCH values to use
to determine little or big endian.

Only error out about not being able to determine endianess if
TARGET_ENDIANNESS is empty and not cross-compiling.

Obtained from: Juniper Networks, Inc.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped
Build Status
Buildable 60248
Build 57132: arc lint + arc unit

Event Timeline

Adjusted little endian list

I'm a little confused by this change - it doesn't seem notably clearer to me. There seems to be a functional change/improvement that isn't really described in the commit message.

I'm a little confused by this change - it doesn't seem notably clearer to me.

In what way? A set of lists is often easier to manage (and clearer, especially in a diff) than a pile of or'd conditional expressions.

There seems to be a functional change/improvement that isn't really described in the commit message.

Are you referring to the host part?

A set of lists is often easier to manage (and clearer, especially in a diff) than a pile of or'd conditional expressions.

I think it's a bit of a toss-up -- the set of targets in the two lists is not large and does not change frequently. I'll grant you that the two lists are somewhat nicer than the large set if if-or conditions, but N_$e= ${MACHINE_ARCH_LIST.$e:@m@N$m@:ts:} makes up for it by taking a while to figure out.

Is the host change fixing a bug?

A set of lists is often easier to manage (and clearer, especially in a diff) than a pile of or'd conditional expressions.

I think it's a bit of a toss-up -- the set of targets in the two lists is not large and does not change frequently. I'll grant you that the two lists are somewhat nicer than the large set if if-or conditions, but N_$e= ${MACHINE_ARCH_LIST.$e:@m@N$m@:ts:} makes up for it by taking a while to figure out.

It's a bit of a toss-up from an understanding standpoint, I suppose, if one is not used to doing that sort of manipulation. At Juniper, we have been using this sort of construct with bmake for many years, so it is somewhat second nature at this point.

Is the host change fixing a bug?

Yes, the host change fixes a bug that can occur when building with dirdeps build.

sjg added inline comments.
share/mk/bsd.endian.mk
16

I thnk you could simplify this with M_ListToSkip:

N_$e = ${MACHINE_ARCH_LIST.$e:${M_ListToSkip}}

possibly use := too

26

FWIW I find this sort of construct scales (mentally) far better than a or'd list of conditionals. Here is is quite clear that we are after arches which are little endian.

Granted some folk find :M a more natural test than :N but the later as the huge advantage of being cumulative. Testing multiple values using :M is more complicated (see M_ListToMatch in share/mk/local.sys.env.mk)

Updated to use ${M_ListToSkip}

Looks ok to me

share/mk/bsd.endian.mk
47

edianness? or however that would be spelt