Re: autogen version testing in fixincludes/genfixes
Basile Starynkevitch writes:
> Hello
>
> With the autogen (GNU AutoGen) 5.11.9 on my Linux/Debian/Sid (or
> perhaps /Experimental) the genfixes script fail, because of the version
> test.
>
> The following patch corrects that.
>
> Index: fixincludes/genfixes
> ===
> --- fixincludes/genfixes (revision 174734)
> +++ fixincludes/genfixes (working copy)
> @@ -62,7 +62,7 @@
> AG="autogen $AG"
> set -e
>
> -if [ -z "`${AG} -v | fgrep 'Ver. 5.'`" ]
> +if [ -z "`${AG} -v | fgrep ' 5.'`" ]
What happens when autogen 6 is released?
Andreas.
--
Andreas Schwab, sch...@redhat.com
GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E
"And now for something completely different."
Is it a typo in treestruct.def?
Hi, I find the printable names are both "label decl" for TS_LABEL_DECL and TS_TYPE_DECL in treestruct.def (trunk), DEFTREESTRUCT(TS_LABEL_DECL, "label decl") DEFTREESTRUCT(TS_RESULT_DECL, "result decl") DEFTREESTRUCT(TS_CONST_DECL, "const decl") DEFTREESTRUCT(TS_TYPE_DECL, "label decl") Is it a typo? Thanks, Mingjie
Re: Is it a typo in treestruct.def?
Mingjie Xing writes: > I find the printable names are both "label decl" for TS_LABEL_DECL and > TS_TYPE_DECL in treestruct.def (trunk), > > DEFTREESTRUCT(TS_LABEL_DECL, "label decl") > DEFTREESTRUCT(TS_RESULT_DECL, "result decl") > DEFTREESTRUCT(TS_CONST_DECL, "const decl") > DEFTREESTRUCT(TS_TYPE_DECL, "label decl") > > Is it a typo? Looks like it. Thanks. Ian
The Linux binutils 2.21.52.0.1 is released
Hi,
If you are using the Linux binutils 2.21.51.0.9, please update as
soon as you can to fix an x86 linker regression: PRs 12833/12837/12859.
---
This is the beta release of binutils 2.21.52.0.1 for Linux, which is
based on binutils 2011 0608 in CVS on sourceware.org plus various
changes. It is purely for Linux.
All relevant patches in patches have been applied to the source tree.
You can take a look at patches/README to see what have been applied and
in what order they have been applied.
Starting from the 2.21.51.0.3 release, you must remove .ctors/.dtors
section sentinels when building glibc or other C run-time libraries.
Otherwise, you will run into:
http://sourceware.org/bugzilla/show_bug.cgi?id=12343
Starting from the 2.21.51.0.2 release, BFD linker has the working LTO
plugin support. It can be used with GCC 4.5 and above. For GCC 4.5, you
need to configure GCC with --enable-gold to enable LTO plugin support.
Starting from the 2.21.51.0.2 release, binutils fully supports compressed
debug sections. However, compressed debug section isn't turned on by
default in assembler. I am planning to turn it on for x86 assembler in
the future release, which may lead to the Linux kernel bug messages like
WARNING: lib/ts_kmp.o (.zdebug_aranges): unexpected non-allocatable section.
But the resulting kernel works fine.
Starting from the 2.20.51.0.4 release, no diffs against the previous
release will be provided.
You can enable both gold and bfd ld with --enable-gold=both. Gold will
be installed as ld.gold and bfd ld will be installed as ld.bfd. By
default, ld.bfd will be installed as ld. You can use the configure
option, --enable-gold=both/gold to choose gold as the default linker,
ld. IA-32 binary and X64_64 binary tar balls are configured with
--enable-gold=both/ld --enable-plugins --enable-threads.
Starting from the 2.18.50.0.4 release, the x86 assembler no longer
accepts
fnstsw %eax
fnstsw stores 16bit into %ax and the upper 16bit of %eax is unchanged.
Please use
fnstsw %ax
Starting from the 2.17.50.0.4 release, the default output section LMA
(load memory address) has changed for allocatable sections from being
equal to VMA (virtual memory address), to keeping the difference between
LMA and VMA the same as the previous output section in the same region.
For
.data.init_task : { *(.data.init_task) }
LMA of .data.init_task section is equal to its VMA with the old linker.
With the new linker, it depends on the previous output section. You
can use
.data.init_task : AT (ADDR(.data.init_task)) { *(.data.init_task) }
to ensure that LMA of .data.init_task section is always equal to its
VMA. The linker script in the older 2.6 x86-64 kernel depends on the
old behavior. You can add AT (ADDR(section)) to force LMA of
.data.init_task section equal to its VMA. It will work with both old
and new linkers. The x86-64 kernel linker script in kernel 2.6.13 and
above is OK.
The new x86_64 assembler no longer accepts
monitor %eax,%ecx,%edx
You should use
monitor %rax,%ecx,%edx
or
monitor
which works with both old and new x86_64 assemblers. They should
generate the same opcode.
The new i386/x86_64 assemblers no longer accept instructions for moving
between a segment register and a 32bit memory location, i.e.,
movl (%eax),%ds
movl %ds,(%eax)
To generate instructions for moving between a segment register and a
16bit memory location without the 16bit operand size prefix, 0x66,
mov (%eax),%ds
mov %ds,(%eax)
should be used. It will work with both new and old assemblers. The
assembler starting from 2.16.90.0.1 will also support
movw (%eax),%ds
movw %ds,(%eax)
without the 0x66 prefix. Patches for 2.4 and 2.6 Linux kernels are
available at
http://www.kernel.org/pub/linux/devel/binutils/linux-2.4-seg-4.patch
http://www.kernel.org/pub/linux/devel/binutils/linux-2.6-seg-5.patch
The ia64 assembler is now defaulted to tune for Itanium 2 processors.
To build a kernel for Itanium 1 processors, you will need to add
ifeq ($(CONFIG_ITANIUM),y)
CFLAGS += -Wa,-mtune=itanium1
AFLAGS += -Wa,-mtune=itanium1
endif
to arch/ia64/Makefile in your kernel source tree.
Please report any bugs related to binutils 2.21.52.0.1 to
hjl.to...@gmail.com
and
http://www.sourceware.org/bugzilla/
Changes from binutils 2.21.51.0.9:
1. Update from binutils 2011 0608.
2. Fix an x86 linker regression. PRs 12833/12837/12859.
3. Fix an x86-64 large model TLS linker bug. PR 12809.
4. Fix LTO bugs. PRs 12758/12760.
5. Add a new linker switch, -plugin-save-temps.
6. Fix an linker bug for warning on common symbol in archive.
7. Fix warning support when building shared library. PR 12761.
8. Reduce linker memory usage when linking many small object files.
PR 12682.
9. Fix an think archive bug. PR 12710.
10. Fix a TLS linker bug. PR 12763.
11. Improve gold.
12. Improve DWARF dump support.
13. Improve XCOFF support.
14. Improve arm sup
Re: autogen version testing in fixincludes/genfixes
On Wed, 08 Jun 2011 10:07:20 +0200
Andreas Schwab wrote:
> Basile Starynkevitch writes:
>
> > Hello
> >
> > With the autogen (GNU AutoGen) 5.11.9 on my Linux/Debian/Sid (or
> > perhaps /Experimental) the genfixes script fail, because of the version
> > test.
> >
> > The following patch corrects that.
> >
> > Index: fixincludes/genfixes
> > ===
> > --- fixincludes/genfixes(revision 174734)
> > +++ fixincludes/genfixes(working copy)
> > @@ -62,7 +62,7 @@
> > AG="autogen $AG"
> > set -e
> >
> > -if [ -z "`${AG} -v | fgrep 'Ver. 5.'`" ]
> > +if [ -z "`${AG} -v | fgrep ' 5.'`" ]
>
> What happens when autogen 6 is released?
I don't know, but I would imagine that autogen -v gave a different
string between 5.11.9 and some previous version, which probably was
also a 5.xx (not too far, since it worked on Debian/Sid a month ago)
What I find strange is to fgrep for the 'Ver.' string. The digit 5 is
ok for me. Here is what I get today:
% autogen --version
autogen (GNU AutoGen) 5.11.9
% autogen -v
autogen (GNU AutoGen) 5.11.9
You see, not Ver. string in it.
And current autogen behavior is not surprising; several other GNU
utilities have the same format : % ls --version
ls (GNU coreutils) 8.5
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
. This is free software: you are free
to change and redistribute it. There is NO WARRANTY, to the extent
permitted by law.
Written by Richard M. Stallman and David MacKenzie.
% gcc --version
gcc (Debian 4.6.0-10) 4.6.1 20110526 (prerelease)
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is
NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.
% find --version
find (GNU findutils) 4.5.10
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
. This is free software: you are free
to change and redistribute it. There is NO WARRANTY, to the extent
permitted by law.
Written by Eric B. Decker, James Youngman, and Kevin Dalley.
Built using GNU gnulib version 25d7f3a59bfdc7aaca4a016f687826883a55bef3
Features enabled: D_TYPE O_NOFOLLOW(enabled) LEAF_OPTIMISATION FTS
(FTS_CWDFD) CBO(level=2)
% autoconf --version
autoconf (GNU Autoconf) 2.64
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv2+: GNU GPL version 2 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Written by David J. MacKenzie and Akim Demaille.
% ld --version
GNU ld (GNU Binutils for Debian) 2.21.51.20110601
Copyright 2011 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms
of the GNU General Public License version 3 or (at your option) a later
version. This program has absolutely no warranty.
So most of the GNU tools I have have a quite similar format for telling
their version. The first line of the output of --version don't have a
Ver. string it it.
Of course, I have LANG=C in all cases.
Regards
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Re: autogen version testing in fixincludes/genfixes
Basile Starynkevitch writes: > You see, not Ver. string in it. $ autogen -v autogen (GNU AutoGen) - The Automated Program Generator - Ver. 5.11.1 Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: autogen version testing in fixincludes/genfixes
On Wed, 08 Jun 2011 20:52:51 +0200
Andreas Schwab wrote:
> Basile Starynkevitch writes:
>
> > You see, not Ver. string in it.
>
> $ autogen -v
> autogen (GNU AutoGen) - The Automated Program Generator - Ver. 5.11.1
I might believe that could be more a issue in autogen than in GCC.
And I also believe that the minuscule patch I am proposing in
http://gcc.gnu.org/ml/gcc/2011-06/msg00081.html
should work on your system too. Could you try it please?
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Re: autogen version testing in fixincludes/genfixes
Basile Starynkevitch writes: > And I also believe that the minuscule patch I am proposing in > http://gcc.gnu.org/ml/gcc/2011-06/msg00081.html > should work on your system too. Could you try it please? That's not the point. The point is, if you patch, you should do it right. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: autogen version testing in fixincludes/genfixes
On Wed, 08 Jun 2011 21:54:56 +0200
Andreas Schwab wrote:
> Basile Starynkevitch writes:
>
> > And I also believe that the minuscule patch I am proposing in
> > http://gcc.gnu.org/ml/gcc/2011-06/msg00081.html
> > should work on your system too. Could you try it please?
>
> That's not the point. The point is, if you patch, you should do it
> right.
But what are your thinking of? I don't catch it (i.e. I don't guess
your thoughts).
And I would imagine that autogen version 6 is so far away in the future
that we can't guess its behavior. I don't know why the script is
testing the version...
Regards.
Cheers.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Re: Disabling Secondary Tests
On 6/6/11, Janis Johnson wrote:
> On 06/03/2011 11:14 AM, Lawrence Crowl wrote:
>> The PPH project has tests that compile two different ways, and
>> then compare the assembly. If either of the compiles fails, the
>> comparison will fail. We'd like to simply not run the comparison.
>>
>> We currently have:
>>
>> set have_errs [llength [grep $test "{\[ \t\]\+dg-error\[\t\]\+.*\[
>> \t\]\+}"]]
>> # Compile the file the first time for a base case.
>> dg-test -keep-output $test "$options -I." ""
>>
>> if { $have_errs } {
>>verbose -log "regular compilation failed"
>>fail "$nshort $options, regular compilation failed"
>>return
>> }
>>
>> But that only stops subsequent actions when the test is known
>> a priori to have errors. How do we detect compilation errors,
>> so as to skip the remainder of the actions?
>
> Complicated GCC tests do this by using local procs instead of dg-runtest
> and dg-test. See, for example, gcc.dg/lto/lto.exp,
> gcc.dg/compat/compat.exp and gcc.dg/tree-prof/tree-prof.exp, which use
> lto.exp, compat.exp and profopt.exp from GCC's testsuite/lib. Those
> have scenarios in which further testing is skipped after a compile or
> link fails.
So, I ended up changing the definition of fail from "reports test
failing" to "does not produce an assembly file". We really need
the latter for comparison, so it is the true measure. Once I made
that change in orientation, I was able to achieve what I wanted.
The simple part is the regular compile.
# Compile the file the first time for a base case.
set dg-do-what-default compile
dg-test -keep-output $test "$options -I." ""
# Quit if it did not compile successfully.
if { ![file_on_host exists "$bname.s"] } {
# All regular compiles should pass.
fail "$nshort $options (regular assembly missing)"
return
}
The complicated part is the compile we are comparing against, which
required knowing whether or not a compile failure is expected. For
that we grep for dg-xfail-if and the appropriate option.
# Compile a second time using the pph files.
dg-test -keep-output $test "$options $mapflag -I." ""
# Quit if it did not compile successfully.
if { ![file_on_host exists "$bname.s"] } {
# Expect assembly to be missing when the compile is an expected fail.
if { ![llength [grep $test "dg-xfail-if.*-fpph-map"]] } {
fail "$nshort $options (pph assembly missing)"
}
return
}
--
Lawrence Crowl
Adding fstack-protector prologue to get_pc_thunk for targets with TARGET_PAD_SHORT_FUNCTION
Let's say I am compiling for a target that has
TARGET_PAD_SHORT_FUNCTION (example: i386 Atom) and that the
compilation flags are -fPIE -fstack-protector.
For certain functions, the starting code sequence will look like the following:
function:
call__i686.get_pc_thunk.bx
addl$_GLOBAL_OFFSET_TABLE_, %ebx
movl%gs:20, %eax # Stack-guard init
movl%eax, -12(%ebp) # Stack-guard init
__i686.get_pc_thunk.bx:
.LFB2:
nop
nop
nop
nop
nop
nop
nop
nop
movl(%esp), %ebx
ret
You can generate this by running the following:
echo "int global; void function(){global = 2;} int main(){function();
}" | ./bin/gcc -fPIE -S -fstack-protector-all -mtune=atom -march=atom
-m32 -xc -o /dev/stdout - | egrep -A10 "function:|.bx:"
Now, what I want to do is move stack guard initialization part
(consisting of the two instructions I have commented as "Stack-guard
init" into get_pc_thunk.bx for those functions that have both the
stack guard and a call to get_pc_thunk.bx. The compiler should
generate a "stack_guarded_get_pc_thunk.bx" that will do move the
%gs:20 value to the correction location on the stack instead of
executing nops. In this way some useful work can be done instead of
nops.
As far as I understand, the stack guard part is done in function.c
(called by cfgexpand.c) which adds the prologue and epilogue to the
protected functions. At this point, we are still target-independent.
The get_pc_thunk.bx is generated by the target-specific
config/i386/i386.c part (ix86_file_end).
How should I go about creating such a patch that should:
1. Check if a function has both stack guard as well as access to a
global (which would result in having the get_pc_thunk call).
2. Remove the stack guard prologue instructions.
3. Replace calls to get_pc_thunk.bx in that function to
stack_guarded_get_pc_thunk.
Specifically, what phase should this be done in?
Thanks,
Re: Adding fstack-protector prologue to get_pc_thunk for targets with TARGET_PAD_SHORT_FUNCTION
asharif tools writes: > function: > call__i686.get_pc_thunk.bx > addl$_GLOBAL_OFFSET_TABLE_, %ebx > movl%gs:20, %eax # Stack-guard init > movl%eax, -12(%ebp) # Stack-guard init > Now, what I want to do is move stack guard initialization part > (consisting of the two instructions I have commented as "Stack-guard > init" into get_pc_thunk.bx for those functions that have both the > stack guard and a call to get_pc_thunk.bx. The compiler should > generate a "stack_guarded_get_pc_thunk.bx" that will do move the > %gs:20 value to the correction location on the stack instead of > executing nops. In this way some useful work can be done instead of > nops. I don't understand how you can do that. The offset from %ebp will be different in different functions. When optimizing, it is likely to be an offset from %esp instead. The scratch register used may also be different; consider functions with __attribute__ ((regparm (2))), or the use of -mregparm=2. > As far as I understand, the stack guard part is done in function.c > (called by cfgexpand.c) which adds the prologue and epilogue to the > protected functions. At this point, we are still target-independent. > > The get_pc_thunk.bx is generated by the target-specific > config/i386/i386.c part (ix86_file_end). > > How should I go about creating such a patch that should: > > 1. Check if a function has both stack guard as well as access to a > global (which would result in having the get_pc_thunk call). > 2. Remove the stack guard prologue instructions. > 3. Replace calls to get_pc_thunk.bx in that function to > stack_guarded_get_pc_thunk. > > Specifically, what phase should this be done in? If you can do this, do it at final, in the expansion for the stack_set and set_got insns. Ian
Re: Generate annotations for a binary translator
Hi, all > Can I dump other information such as CFG in a similar way as register > usage does? At the end of the link belows, http://gcc.gnu.org/onlinedocs/gccint/Maintaining-the-CFG.html#Maintaining-the-CFG It says, "Note that at present, the representation of control flow in the tree representation is discarded before expanding to RTL. Long term the CFG should be maintained and "expanded" to the RTL representation along with the function tree itself." Does this mean in the end of GCC compilation, the CFG information is lost? Thanks! Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667
Re: Generate annotations for a binary translator
陳韋任 writes: >> Can I dump other information such as CFG in a similar way as register >> usage does? > > At the end of the link belows, > > http://gcc.gnu.org/onlinedocs/gccint/Maintaining-the-CFG.html#Maintaining-the-CFG > > It says, > > "Note that at present, the representation of control flow in the tree > representation is discarded before expanding to RTL. Long term the CFG > should be maintained and "expanded" to the RTL representation along > with the function tree itself." > > Does this mean in the end of GCC compilation, the CFG information is > lost? Thanks! That documentation is out of date. The CFG is now retained through most of the RTL passes. Ian
