Re: [testsuite] don't use lto plugin if it doesn't work
[Adding gcc@] On Jun 26, 2012, "H.J. Lu" wrote: > On Tue, Jun 26, 2012 at 3:39 PM, Mike Stump wrote: >> On Jun 26, 2012, at 2:04 PM, Alexandre Oliva wrote: >>> I test i686-linux-gnu in a presumably unusual setting >> >> I like the setup and testing... >> >>> This worked fine for regression testing, but I've recently realized >>> (with the PR49888/53671 mishap) that I'm getting tons of LTO testsuite >>> failures (before and after, so no regression), because the 32-bit LTO >>> plugin built in this setting can't possibly be used by the 64-bit linker >>> installed on the system. Obviously, passing -melf_i386 to the linker >>> through the wrapper is not enough for it to be able to dlopen a 32-bit >>> plugin ;-) >> So, let's kick this back to the gcc list for all the interested >> parties to chime in on... I'd rather have 5 interested people >> architect the right, nice solution that is engineered to work and >> then use it. >> H.J.'s solution seems like the most reasonable short term solution It's not a “solution”, it's just the same local arrangement I mentioned I was leaning towards, after fixing the problem in the test harness, that lets GCC use the plugin and fail even after explicitly testing for that. I don't see how that can possibly be perceived as not a bug. Which is not to say that there aren't *other* bugs in place, and that some of them might alleviate this one. >> If we build the plugin after sensing the 64-bitness of ld, using the >> flags appropriate for the linker... Then we'd be disobeying the host setting specified or detected by configure. >> failing the build early when mismatched Why? We don't demand a working plugin. Indeed, we disable the use of the plugin if we find a linker that doesn't support it. We just don't account for the possibility of finding a linker that supports plugins, but that doesn't support the one we'll build later. > Bootstrap/test -m32/-mx32 with LTO on -m64 is similar to cross-compile, > in the sense that the native linker may not work with plugin. We just > need to make the right linker available to GCC. My kludge uses PATH. > One can also include binutils source in GCC source tree. These are all reasonable suggestions to make the plugin work. But that's not what the patch addresses, namely what to do during testing when the plugin is found to NOT work. As I wrote in the original post, even if we were to detect that the plugin is not supported and refrain from building it and testing it, it's more valuable that the test summaries explicitly indicate, in each FAIL or XFAIL, that the plugin was not used, rather than make room for uncertainty as to whether the plugin was implicitly used or not. -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer
Re: [x86-64 psABI] RFC: Extend x86-64 psABI to support x32
On Tue, Jun 26, 2012 at 10:56 PM, Mark Butler wrote:
>
>
> On Tuesday, June 26, 2012 3:22:45 PM UTC-6, H.J. wrote:
>>
>> On Tue, Jun 26, 2012 at 2:11 PM, Mark Butler wrote:
>> >
>> >> x32 is designed to replace ia32 where long is 32-bit, not x86-64.
>> >>
>> > I understand, but wouldn't L64P32 be much better in the long run? In
>> > terms
>> > of compatibility with LP64, and an LP64 kernel in particular? The
>> > structure
>> > layouts of any structure that did not contain pointers would be
>> > identical,
>> > for example. struct timeval, struct timespec, struct stat, and on and
>> > on...
>>
>> Linux/x32 uses the same layout for struct timeval, struct timespec, struct
>> stat,
>> as Linux/x86-64. It is orthogonal to L64 vs L32.
>>
> If POSIX requires struct timespec to look like this:
>
> struct timespec {
> time_t tv_sec;
> long tv_nsec;
> }
>
> then how can an ABI with 32 bit longs have the same struct timespec layout
> as an ABI with 64 bit longs?
>
We changed it to
struct timespec
{
__time_t tv_sec;/* Seconds. */
__syscall_slong_t tv_nsec; /* Nanoseconds. */
};
--
H.J.
Re: Add STB_SECONDARY to gABI
Hi, Resending with plain text. Here is the final proposal to add STB_SECONDARY to gABI. Any comments? Thanks. -- H.J. --- We want to provide a relocatable object which can take advantage of all versions of a supported OS. For a function, foo, in the C library, we can use it only if it is available on all versions of the C library or we provide our own implementation of foo. With our own foo, the one in the C library will never be used. Here is a proposal to add STB_SECONDARY to gABI to support the secondary definition so that a software vendor can provide an alternative implementation in case it isn't available in the C library. STB_SECONDARY Secondary symbols are similar to weak symbols, but their definitions have lower precedence than global and week symbols. The difference between secondary symbols and weak symbols are 1. The link editor must search archive library and extract archive members to resolve defined and undefined secondary symbol. 2. When the link editor searches a shared object, it must honor the global or weak definition in the shared object and ignore the secondary one with the same name. 3. The link editor ignores the secondary definition if there is a global, weak or common definition with the same name. Multiple secondary definitions with the same name will not cause an error. The first appearance of the secondary definition should be honored and the rest are ignored. 4. The link editor may treat the secondary definition in the shared object as a global definition. The purpose of this symbol binding is to provide the primary definition as a global, weak or common symbol in an archive library or a shared object while keeping a secondary definition in a relocatable object. If there is no primary definition, the secondary definition will be used. When secondary definitions become part of an executable or shared object, linker may convert them to global or local definitions. At run-time, when resolving a symbol, after seeing a secondary definition, the dynamic linker must keep searching until a global or weak definition is found. If a global or weak definition is found, it will be used to satisfy the symbol lookup. Otherwise, the secondary definition will be used. If the dlopen loads a global or weak definition after the program has already resolved references to a secondary definition, those references remain bound to the secondary definition. Any references resolved after the dlopen, for which the dlopened module is included in the module search list, would be resolved to the global or weak definition. STB_SECONDARY is defined as: #define STB_SECONDARY 3 /* Secondary symbol */ NOTE: The behavior of secondary symbols in areas not specified by this proposal is implementation defined.
Re: [x86-64 psABI] RFC: Extend x86-64 psABI to support x32
On Wed, 2012-06-27 at 05:01 -0700, H.J. Lu wrote:
> On Tue, Jun 26, 2012 at 10:56 PM, Mark Butler wrote:
> >
> >
> > On Tuesday, June 26, 2012 3:22:45 PM UTC-6, H.J. wrote:
> >>
> >> On Tue, Jun 26, 2012 at 2:11 PM, Mark Butler wrote:
> >> >
> >> >> x32 is designed to replace ia32 where long is 32-bit, not x86-64.
> >> >>
> >> > I understand, but wouldn't L64P32 be much better in the long run? In
> >> > terms
> >> > of compatibility with LP64, and an LP64 kernel in particular? The
> >> > structure
> >> > layouts of any structure that did not contain pointers would be
> >> > identical,
> >> > for example. struct timeval, struct timespec, struct stat, and on and
> >> > on...
> >>
> >> Linux/x32 uses the same layout for struct timeval, struct timespec, struct
> >> stat,
> >> as Linux/x86-64. It is orthogonal to L64 vs L32.
> >>
> > If POSIX requires struct timespec to look like this:
> >
> > struct timespec {
> > time_t tv_sec;
> > long tv_nsec;
> > }
> >
> > then how can an ABI with 32 bit longs have the same struct timespec layout
> > as an ABI with 64 bit longs?
> >
>
> We changed it to
>
> struct timespec
> {
> __time_t tv_sec; /* Seconds. */
> __syscall_slong_t tv_nsec;/* Nanoseconds. */
> };
>
I think that means you fails to conform to posix unless
__syscall_slong_t is an alias for long.
If I understand the posix spec correctly then, in a conforming
implementation,
struct timespec ts;
if (sizeof(long) != sizeof(ts.tv_nsec))
abort();
never calls abort.
For your purpose it would have been much better if tv_nsec had been
specified with a type with allowed values, similarly to how suseconds_t
that is used for timeval.tv_usec is specified.
I suppose this is something to bring up for posix-next.
/MF
Re: [x86-64 psABI] RFC: Extend x86-64 psABI to support x32
On Wed, Jun 27, 2012 at 11:24 AM, Magnus Fromreide wrote:
> On Wed, 2012-06-27 at 05:01 -0700, H.J. Lu wrote:
>> On Tue, Jun 26, 2012 at 10:56 PM, Mark Butler wrote:
>> >
>> >
>> > On Tuesday, June 26, 2012 3:22:45 PM UTC-6, H.J. wrote:
>> >>
>> >> On Tue, Jun 26, 2012 at 2:11 PM, Mark Butler wrote:
>> >> >
>> >> >> x32 is designed to replace ia32 where long is 32-bit, not x86-64.
>> >> >>
>> >> > I understand, but wouldn't L64P32 be much better in the long run? In
>> >> > terms
>> >> > of compatibility with LP64, and an LP64 kernel in particular? The
>> >> > structure
>> >> > layouts of any structure that did not contain pointers would be
>> >> > identical,
>> >> > for example. struct timeval, struct timespec, struct stat, and on and
>> >> > on...
>> >>
>> >> Linux/x32 uses the same layout for struct timeval, struct timespec, struct
>> >> stat,
>> >> as Linux/x86-64. It is orthogonal to L64 vs L32.
>> >>
>> > If POSIX requires struct timespec to look like this:
>> >
>> > struct timespec {
>> > time_t tv_sec;
>> > long tv_nsec;
>> > }
>> >
>> > then how can an ABI with 32 bit longs have the same struct timespec layout
>> > as an ABI with 64 bit longs?
>> >
>>
>> We changed it to
>>
>> struct timespec
>> {
>> __time_t tv_sec; /* Seconds. */
>> __syscall_slong_t tv_nsec; /* Nanoseconds. */
>> };
>>
>
> I think that means you fails to conform to posix unless
> __syscall_slong_t is an alias for long.
That is true.
> If I understand the posix spec correctly then, in a conforming
> implementation,
>
> struct timespec ts;
> if (sizeof(long) != sizeof(ts.tv_nsec))
> abort();
>
> never calls abort.
It will abort on x32.
> For your purpose it would have been much better if tv_nsec had been
> specified with a type with allowed values, similarly to how suseconds_t
> that is used for timeval.tv_usec is specified.
>
> I suppose this is something to bring up for posix-next.
>
Yes, that is the intention.
--
H.J.
Re: [testsuite] don't use lto plugin if it doesn't work
On Jun 27, 2012, at 2:07 AM, Alexandre Oliva wrote: > Why? We don't demand a working plugin. Indeed, we disable the use of > the plugin if we find a linker that doesn't support it. We just don't > account for the possibility of finding a linker that supports plugins, > but that doesn't support the one we'll build later. If this is the preferred solution, then having configure check the 64-bitness of ld and turning off the plugin altogether on mismatches sounds like a reasonable course of action to me.
Are we fast yet?
Hello list! you may have thought I'd disappeared but here I am, after weeks of working on a small project of mine. What started as a very small hack for visualising callgrind's profiles is now an -experimental still- website, a GCC version of mozilla's "arewefastyet.com". For now you can see it at: http://teras-ics.mooo.com:8003/ Of course it has lots of problems so I'd appreciate all comments. Since I didn't have a clue about web development, let's say that the UI is not /that/ intuitive: * The dots on the first plot are clickable and each open a different profile breakdown. * In each profile breakdown, functions are selectable and the blue thing that shows at the bottom is actually a link (I know it doesn't show...) that loads the same profile, but with the selected function as baseline. * The profile breakdown CGI has also a hidden query string argument that I couldn't find a nice way to expose in the SVG: &f=funcname selects the function by name, e.g. if you want to find out the hottest callers for malloc you can go to: http://teras-ics.mooo.com:8003/cgi-bin/callgrind_svg.cgi?r=4.8-20120506&f=xmalloc Many more small SVG issues took most of my time but I won't start here, I'll save my wrath for the SVG-developers list. :-) Besides the UI issues I still have some other open issues to think of, ideas are welcome here too: * Some function names are not demangled correctly, I'll first try valgrind's trunk and maybe demangle anything that remains manually. * Compile all GCC versions against specific glibc (and gmp/mpc/mpfr secondly) to avoid fluctuations when the system upgrades. I've tried linking statically and works well (as a bonus it also resolves all the name mangling issues) but I'm really short on space now... so what's the recommended way to link GCC against specific glibc (I was expecting some --with-libc configure option)? * Expose more of the data valgrind gives (like full source annotation) * Unfortunately Callgrind doesn't save the full stack trace so what you see is a statistical breakdown for callees. It doesn't necessarily mean that a call path displayed actually exists deeper than its first level. But the numbers add-up so this is minor. So I started this thinking that there was not something similar for GCC. Until I heard that http://gcc.opensuse.org actually measures compilation time and memory usage a long time now. Hopefully this project of mine adds some extra value by focusing cleanly on GCC's performance and by allowing to actually spot the regressions easily. To demonstrate this I annotated the frontpage plot manually, that is I wrote the comments after diving into the callgraphs. It actually took only a few minutes of switching tabs back and forth to notice the differences, so I created the annotations as an example. (On another note this led me to notice that a few patches of mine actually made it in trunk, cool. :-) Last but not least credits to the websites that inspired me, namely Mozilla's "arewefastyet.com" [1] and the original flamegraph at [2]. [1] http://arewefastyet.com/ [2] http://dtrace.org/blogs/brendan/2012/03/17/linux-kernel-performance-flame-graphs/ Thanks, Dimitris P.S. For anyone interested, I've put the main source code -parsing of Callgrind output and SVG generation, but /not/ the testing scripts/cron jobs- in my private directory at Launchpad, but it's still very ugly and hacky so beware: http://bazaar.launchpad.net/~jimis/+junk/callgrind_parser/files
Re: [onlinedocs]: No more automatic rebuilt?
Andreas Schwab schrieb: "Joseph S. Myers" writes: Since I updated texinfo.tex, update_web_docs_svn has produced errors that don't make any sense to me. Most likely due to this missing change: 2012-06-05 Karl Berry * doc/texinfo.tex (\txiescapepdf): check \pdfescapestring against \thisisundefined, not \relax. Of course. Bug report from Marco Maggi, 05 Jun 2012 12:07:02. Tested with make pdf, installed as obvious. Andreas. * doc/include/texinfo.tex: Update to version 2012-06-05.14. The admin logs look clean now, but the generated documents still didn't make it to the website, e.g. changes after 2012-05-29 like the mentioned SVN 188070. Johann
