From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Patches and discussions about the oe-core layer
<openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH 08/10] target gcc: gcc-multilib-setup
Date: Wed, 22 Feb 2012 13:21:14 +0000 [thread overview]
Message-ID: <1329916874.20261.135.camel@ted> (raw)
In-Reply-To: <e63f62b491b637aa4d97174fb7a0682fff6a872b.1329892604.git.nitin.a.kamble@intel.com>
Hi Nitin,
This is a good start but I think this still needs a little bit of work.
I'm particularly concerned it appears necessary to rewrite all the tune
files to make this work, we shouldn't need to do that.
I've given this some thought and explained how I think we can avoid this
and some other issues below.
On Tue, 2012-02-21 at 22:37 -0800, nitin.a.kamble@intel.com wrote:
> +python do_gcc_multilib_setup() {
> + import re
> +
> + # do this only for target recipe
> + if d.getVar('PN', 1) != 'gcc':
> + return
Please use ", True" instead of ", 1" in all new code.
> + srcdir = d.getVar('S', 1) or ''
> +
> + multilibs = d.getVar('MULTILIB_VARIANTS', 1) or ''
> + if multilibs == '':
> + return
Even in the non multilib case, we still need to alter the configuration
to match whatever library layout is being used (the values of
base_libdir and libdir) as the 64bithack.patch does now.
> + gcc_target_config_files = { 'x86_64' : 'gcc/config/i386/t-linux64',
> + 'mips' : 'gcc/config/mips/t-linux64' ,
> + 'ppc' : 'gcc/config/rs6000/t-linux64' }
> +
> + gcc_header_config_files = { 'x86_64' : 'gcc/config/i386/linux64.h',
> + 'mips' : 'gcc/config/mips/linux64.h' ,
> + 'ppc' : 'gcc/config/rs6000/linux64.h' }
What about building 64 bit as a multilib on an i586 system? This also
doesn't account for powerpc64.
For i586, we probably need to add the configure option
--enable_targets=all and then we can add i*86 to the above list also
pointing at gcc/config/i386/t-linux64. We'd need more investigation to
figure out what is needed for powerpc64.
> + target_arch = d.getVar('TARGET_ARCH', 1) or ''
> +
> + if target_arch not in gcc_target_config_files:
> + bb.warn('gcc multilib setup is not supported for TARGET_ARCH=' + target_arch)
> + return
> +
> + gcc_multilib_target_config_file = gcc_target_config_files[target_arch]
> +
> + gcc_multilib_header_config_file = gcc_header_config_files[target_arch]
> +
> + ml_list = ['DEFAULTTUNE']
> + for ml in multilibs.split(' '):
> + ml_list.append('DEFAULTTUNE_virtclass-multilib-' + ml)
> +
> + tunes_32 = ['x86', 'core2', 'i586', 'mips', 'mipsel', 'mips-nf', 'mipsel-nf', 'powerpc', 'powerpc-nf']
> + tunes_64 = ['x86-64', 'core2-64', 'mips64', 'mips64el', 'mips64-nf', 'mips64el-nf', 'powerpc64']
> + tunes_x32 = ['x86-64-x32', 'core2-64-x32']
> + tunes_n32 = ['mips64-n32', 'mips64el-n32', 'mips64-nf-n32', 'mips64el-nf-n32']
I'm afraid I strongly dislike lists of hardcoded values. How about
having the code below that uses this doing something like:
if ml_tune.find("-n32") != -1:
libdirn32 = ml_baselib
elif ml_tune.find("-x32") != -1:
libdirx32 = ml_baselib
elif ml_tune.find("64") != -1:
libdir64 = ml_baselib
else:
libdir32 = ml_baselib
?
This also reminds me that we have an open bug about sanity checking the
multilib configuration. This code would lend itself well to sanity
checking the multilib configuration, e.g. if any of the above variables
all get set to the same library location, that would be an error. I'm
starting to think we may need some library functions to handle this
better.
The sanity checks can be a secondary step and patch but it would be good
to start thinking about this now.
> + libdir32 = 'SYSTEMLIBS_DIR'
> + libdir64 = 'SYSTEMLIBS_DIR'
> + libdirx32 = 'SYSTEMLIBS_DIR'
> + libdirn32 = 'SYSTEMLIBS_DIR'
> +
> + multilib_options = []
> + multilib_dirnames = []
> + multilib_osdirnames = []
> +
> + for ml in ml_list:
> + ml_tune = d.getVar(ml, 1) or ''
> + ml_tune_features = d.getVar('TUNE_FEATURES_tune-' + ml_tune, 1) or ''
> + ml_baselib = d.getVar('BASE_LIB_tune-' + ml_tune, 1) or ''
> +
> + if ml_tune in tunes_32:
> + libdir32 = ml_baselib
> + elif ml_tune in tunes_64:
> + libdir64 = ml_baselib
> + elif ml_tune in tunes_x32:
> + libdirx32 = ml_baselib
> + elif ml_tune in tunes_n32:
> + libdirn32 = ml_baselib
> +
> + ml_tune_ccargs_list = []
> + for feature in ml_tune_features.split():
> + ml_feature_ccargs = d.getVar('TUNE_FEATURE_CCARGS-' + feature, 1) or ''
> + ml_tune_ccargs_list.append(ml_feature_ccargs)
> + ml_tune_ccargs = ' '.join(ml_tune_ccargs_list)
I'm guessing this piece is why you ended up changing all the tune files.
To access this (and other multilib information) you should be able to do
something like:
for ml in multilibs:
localdata = bb.data.createCopy(d)
override = ":virtclass-multilib-" + ml
localdata.setVar("OVERRIDES", localdata.getVar("OVERRIDES", False) + override)
bb.data.update_data(localdata)
tune_ccargs = localdata.getVar("TUNE_CCARGS", True)
tune_features = localdata.getVar("TUNE_FEATURES", True)
baselib = localdata.getVar("BASE_LIB", True)
and here tune_ccargs will get the value applied in each multilib along
with some other variables I noticed you were looking up.
Of course this doesn't get you just the TUNE_FEATURE piece of
tune_ccargs but it does remove the need to re-namespace all the
variables.
> + # take out '-' in parameters
> + multilib_options.append(re.sub(r'^\-+', '', re.sub(r' \-+', ' ', ml_tune_ccargs)))
> + if ml_baselib == 'lib':
> + multilib_dirnames.append('32')
> + else:
> + multilib_dirnames.append(ml_baselib.replace('lib', ''))
> + multilib_osdirnames.append('../' + ml_baselib)
> +
> + with open(srcdir + '/' + gcc_multilib_target_config_file, 'r') as f:
> + filelines = f.read()
> + f.close()
> +
> + # recreate multilib configuration variables
> +
> + filelines = re.sub(r'^\s*MULTILIB_OPTIONS\s*=.*$',
> + 'MULTILIB_OPTIONS = ' + '/'.join(multilib_options),
> + filelines, flags=re.MULTILINE)
> +
> + filelines = re.sub(r'^\s*MULTILIB_DIRNAMES\s*=.*$',
> + 'MULTILIB_DIRNAMES = ' + ' '.join(multilib_dirnames),
> + filelines, flags=re.MULTILINE)
> +
> + filelines = re.sub(r'^\s*MULTILIB_OSDIRNAMES\s*=.*$',
> + 'MULTILIB_OSDIRNAMES = ' + ' '.join(multilib_osdirnames),
> + filelines, flags=re.MULTILINE)
> +
> + with open(srcdir + '/' + gcc_multilib_target_config_file, 'w') as f:
> + f.write(filelines)
> + f.close()
> +
> + with open(srcdir + '/' + gcc_multilib_header_config_file, 'r') as f:
> + filelines = f.read()
> + f.close()
> +
> + # replace lines like
> + # #define GLIBC_DYNAMIC_LINKER32 SYSTEMLIBS_DIR "ld-linux.so.2"
> + # by
> + # #define GLIBC_DYNAMIC_LINKER32 "/lib/" "ld-linux.so.2"
> + # this is needed to put the correct dynamic loader path in the generated binaries
> +
> + filelines = re.sub(r'^(#define\s*GLIBC_DYNAMIC_LINKER32\s*)(SYSTEMLIBS_DIR)(\s*\".*\")$',
> + r'\1"/' + libdir32 + r'/"\3',
> + filelines, flags=re.MULTILINE)
> +
> + filelines = re.sub(r'^(#define\s*GLIBC_DYNAMIC_LINKER64\s*)(SYSTEMLIBS_DIR)(\s*\".*\")$',
> + r'\1"/' + libdir64 + r'/"\3',
> + filelines, flags=re.MULTILINE)
> +
> + filelines = re.sub(r'^(#define\s*GLIBC_DYNAMIC_LINKERX32\s*)(SYSTEMLIBS_DIR)(\s*\".*\")$',
> + r'\1"/' + libdirx32 + r'/"\3',
> + filelines, flags=re.MULTILINE)
> +
> + filelines = re.sub(r'^(#define\s*GLIBC_DYNAMIC_LINKERN32\s*)(SYSTEMLIBS_DIR)(\s*\".*\")$',
> + r'\1"/' + libdirn32 + r'/"\3',
> + filelines, flags=re.MULTILINE)
> +
> + with open(srcdir + '/' + gcc_multilib_header_config_file, 'w') as f:
> + f.write(filelines)
> + f.close()
I'm slightly puzzled why this last open/clode is indented differently to
the first set above. I'm also wondering why you don't do all of this in
one pass over the file and instead use two?
Cheers,
Richard
next prev parent reply other threads:[~2012-02-22 13:29 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-22 6:37 [PATCH 00/10] Enable multilib for target gcc nitin.a.kamble
2012-02-22 6:37 ` [PATCH 01/10] arch-ia32: rearrange tune configuration nitin.a.kamble
2012-02-22 6:37 ` [PATCH 02/10] arch-ia32.inc: restructure TUNE_ARCH definition nitin.a.kamble
2012-02-22 6:37 ` [PATCH 03/10] arch-mips.inc: rearrange for gcc-multilib nitin.a.kamble
2012-02-22 6:37 ` [PATCH 04/10] arch-mips.inc: define TUNE_FEATURE_ARCH vars for multilib tunes nitin.a.kamble
2012-02-22 6:37 ` [PATCH 05/10] arch-powerpc*.inc: rearrange for gcc-multilib nitin.a.kamble
2012-02-22 6:37 ` [PATCH 06/10] arch-powerpc*.inc: rearrange TUNE_ARCH definition nitin.a.kamble
2012-02-22 6:37 ` [PATCH 07/10] gcc: remove the 64bithack patch nitin.a.kamble
2012-02-22 6:37 ` [PATCH 08/10] target gcc: gcc-multilib-setup nitin.a.kamble
2012-02-22 13:21 ` Richard Purdie [this message]
2012-02-22 6:37 ` [PATCH 09/10] libgcc_4.6.bb: Complete quote in definition of FILES_libgcov-dev nitin.a.kamble
2012-02-22 6:37 ` [PATCH 10/10] libgcc: get the gcc header files working nitin.a.kamble
2012-02-22 13:43 ` Richard Purdie
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1329916874.20261.135.camel@ted \
--to=richard.purdie@linuxfoundation.org \
--cc=openembedded-core@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox