Building cross-compilers with sibling package trees
Building a cross compiler from scratch "just works" (as in all one has to do is "configure, make all install") if all of binutils, gcc, newlib, libgloss, libstdc++, etc. are siblings. [At least this use to "just work".] The number of hoops one has to go through when this isn't the case can be painful, especially if one is doing active development on multiple packages (e.g. writing a new port from scratch). Is there any interest in making this easier? [where "this" = keeping packages separate but still having the convenience of a "one-tree" layout] If not, there's no point in reading further. :-) I was thinking that (at least) two things are required: 1) the ability to tell gcc where the other packages are 2) the ability to build gcc, build libc (e.g. newlib), then come back and build libstdc++ For (1), the tree layout might be something like topsrc/Makefile.in topsrc/configure.ac topsrc/configure topsrc/$binutils/gas /binutils /other-binutils-subdirs topsrc/$gcc/gcc /libstdc++-v3 /other-gcc-subdirs topsrc/$newlib/newlib /libgloss /other-newlib-subdirs topsrc/$etc If there were configure arguments (or some such) to tell gcc where to find gas (for example) in this new build tree, then one could continue to have a "one tree" like tree, and topsrc/Makefile.in could orchestrate building of everything. For (2), libstdc++-v3 needs to know where the libc headers are, in the build tree. If libc is newlib, then at least part of newlib needs to be made first (so that targ-include is created) before configuring/building libstdc++-v3. I think topsrc/Makefile.in can easily orchestrate cd'ing into gcc to build gcc, cd'ing into newlib to build newlib, and then cd'ing back into gcc to build libstdc++-v3, but it is a bit of a dance. So, to repeat in case I lost you, is there any interest in making this easier? [where "this" = keeping packages separate but still having the convenience of a "one-tree" layout] Or, if one is writing a new port from scratch, do we just tell folks to either manually hack in a "one-tree" layout or otherwise deal with it by him/herself. Most of the solution is outside the scope of each package, which is good, so one might wonder why bother gcc with this. Some change to gcc would be required to allow it, for example, to create its gas symlink to a different place in the build tree (beyond the current default of ../gas/as-new).
Re: Building cross-compilers with sibling package trees
Eric writes: > > So your target audience is "people who use newlib, use the uberbaum > > build, and who work on multiple gcc trees", right? Seems > > like such a small audience it's not likely to be widely used, > > but that's just my impression. > > I agree unfortunately. Really if you're not wanting to have a single > tree it's more effort than it's worth - either that or split it up into > build and install binutils and then build and install gcc (using > --with-newlib=...). Easily script-able, but I'm pretty sure that's not > what doug wants. You are correct, it's not quite what I'm looking for. The purpose of doing this is to speed up the development process. The existing scripts that take _existing_ and _tested_ releases are fine by me, I don't care much about this aspect. Such scripts are generally run just once and that's it (once the bugs in the scripts are worked out, which is separate from bugs in the tools). And scenarios where the majority of the hacking is on one particular piece aren't really what I'm interested in either - there the majority of the hacking is in one package so often "make" followed by "make check" will continue to "just work". Consider a scenario where c++ folks had to do "make install" of the backend before they could link cc1plus and run dejagnu. And suppose this was standard-operating-procedure. [It's not a real scenario of course, but it does have the right flavor of the problem I wish to solve.] It's the day-to-day development of a fresh port that I want to speed up. If I've gone through a run of "make check-gcc" and fixed some random bugs, with fixes in any or all of libgloss, bfd, or gcc, for example, I'd prefer it if I could just type make and then make check-gcc again. Note that newlib isn't necessarily the libc in use here. It could be any libc, though the context is cross-compilation.
Re: bug 24599
A question for the general group. Is it really the case that it's ok that a testcase clobbers boolean_true_node and sets overflow? (and is this one case of a more general problem?) If that's not unintended, ok, but it seems confusing (aka source of bugs). Or, which is certainly not unexpected, is this another case of something being in transition and the transition isn't complete? Note that I'm treating integer_nonzerop as a red-herring. It's the clobbering of boolean_true_node that I'm concerned about. pinskia at gcc dot gnu dot org writes: > > > --- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-03 18:25 > --- > (In reply to comment #2) > > I'm not sure the root cause of this bug is fixed in 4.1. It looks to me > > like > > it's still there and is only (currently) hidden. Am I mistaken? > > Apply this patch to gcc-4.1-20051029 and recompile the testcase with -O3. > > I'm seeing an abort. If I set a breakpoint on integer_nonzerop and print > > the > > boolean_true_node tree I see it's marked as "overflow". Oops > > Overflow should mean nothing to the optimizers or expanders. It is only a > language term really that should only matter to the front-end. > integer_nonzerop should not be used that much any more, Yes I know it is but > really it needs to be changed to use nonzero_p instead. > > > -- > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24599 > > --- You are receiving this mail because: --- > You reported the bug, or are watching the reporter.
Re: bug 24599
It seems like there's a whole range of issues once boolean_true_node
(or any such global tree node) has been clobbered.
#include
int
main (int argc, char **argv)
{
if ((bool)((1527719483 + 1477819644))) {
}
return 0;
}
bool t1 = true;
---
[EMAIL PROTECTED] gcc]$ ./xgcc -B./ -O3 -S foo2.c -save-temps -pedantic
foo2.c: In function `main':
foo2.c:6: warning: integer overflow in expression
foo2.c: At top level:
foo2.c:12: warning: overflow in constant expression
[EMAIL PROTECTED] gcc]$ ./xgcc -B./ -v
Reading specs from ./specs
Target: i686-pc-linux-gnu
Configured with: ./configure --prefix=/tmp/junk
Thread model: posix
gcc version 4.1.0 20051026 (experimental)
[EMAIL PROTECTED] gcc]$
Re: stabs support in binutils, gcc, and gdb
On Thu, Jan 3, 2013 at 9:52 AM, nick clifton wrote: >> Switching to DWARF causes our build products directory (which contains >> *NONE* of the intermediate files) to swell from 1.2 GB to 11.5 GB. >> Ouch! The DWARF ELF files are 8-12 times the size of the STABS ELF >> files. >> >> If the DWARF files were, say, a factor of 2 the size of the STABS files, >> I could probably sell people on switching to DWARF; but, a factor of 8 >> to 12 is too much. > > > Have you tried using a DWARF compression tool like dwz ? > > http://gcc.gnu.org/ml/gcc/2012-04/msg00686.html > > Or maybe the --compress-debug-sections option to objcopy ? Yeah, that would be really useful data to have. Plus, there's also -gdwarf-4 -fdebug-types-section. So while plain dwarf may be 8-12x of stabs, progress has been made, and we shouldn't base decisions on incomplete analyses. If we had data to refute (or substantiate) claims that dwarf was *still* X% larger than stabs and people were still avoiding dwarf because of it, that would be really useful.
Re: stabs support in binutils, gcc, and gdb
On Fri, Jan 11, 2013 at 6:52 AM, David Taylor wrote: > Doug Evans wrote: >> So while plain dwarf may be 8-12x of stabs, progress has been made, >> and we shouldn't base decisions on incomplete analyses. > > ... > > If I use objcopy --compress-debug-sections to compress the DWARF debug > info (but don't use it on the STABS debug info), then the file size > ratio is 3.4. > > While 3.4 is certainly better than 11.5, unless I can come up with a > solution where the ratio is less than 2, I'm not currently planning on > trying to convince them to switch to DWARF. The 3.4 number is the number I was interested in. Thanks for computing it. There are other things that can reduce the amount of dwarf, but the size reduction can depend on the app of course. I'm thinking of dwz and .debug_types. I wonder what 3.4 changes to with those applied.
Re: stabs support in binutils, gcc, and gdb
On Fri, Jan 11, 2013 at 7:17 PM, Ian Lance Taylor wrote: > On Fri, Jan 11, 2013 at 5:55 PM, Cary Coutant wrote: >> >> Next, I compiled a 5000-line C++ source file at both -O0 and -O2. > > I have to assume that David is working with C code, as stabs debugging > for C++ is nearly unusable. That was my assumption, fwiw.
Re: stabs support in binutils, gcc, and gdb
On Fri, Jan 11, 2013 at 6:55 PM, Cary Coutant wrote: >>> If I use objcopy --compress-debug-sections to compress the DWARF debug >>> info (but don't use it on the STABS debug info), then the file size >>> ratio is 3.4. >>> >>> While 3.4 is certainly better than 11.5, unless I can come up with a >>> solution where the ratio is less than 2, I'm not currently planning on >>> trying to convince them to switch to DWARF. >> >> The 3.4 number is the number I was interested in. >> Thanks for computing it. > > It's not really fair to compare compressed DWARF with uncompressed stabs, is > it? Data is data. Plus I doubt anyone is going to go to the trouble of compressing stabs. Not that I think it's a priori worth the effort to dig deeper, but for another datapoint, Redhat added an lza-compressed mini-dwarf-debug section. I'm not sure what it supports (if anything beyond making backtraces better).
