Re: raising minimum version of Flex

[Gerald Pfeifer]

On Mon, 21 Jan 2007, Ian Lance Taylor wrote:
> That doesn't sound right.  It see flex being run every time I create a
> new object directory, even though I don't modify the flex input files.
> We ship gengtype-lex.c with releases, so people building the compiler
> from releases shouldn't have to worry, but it is still an issue for
> developers.

...and testers.  Ever since MPFR became a mandatory requirement this
has been hurting me and other testers (and reduced test coverage).

Our documentation and my own experience both agree with Ian:

  @item Flex version 2.5.4 (or later)

  Necessary when modifying @file{*.l} files.

  Necessary to build GCC during development because the generated output
  files are not included in the SVN repository.  They are included in
  releases.

I checked several system available to me, and nearly all of them still
run flex 2.5.4.  Some, like SUSE Linux 10.0, are just about a year old.  
openSUSE 10.2 now comes with flex 2.5.33, but FreeBSD, for example, still 
is at flex 2.5.4.  Just some additional data pointes...

Gerald

Re: raising minimum version of Flex

[Václav Haisman]

Gerald Pfeifer wrote:
[...]
> openSUSE 10.2 now comes with flex 2.5.33, but FreeBSD, for example, still 
> is at flex 2.5.4.  Just some additional data pointes...
FreeBSD has version 2.5.33 as textproc/flex port.

--
Vaclav Haisman



signature.asc
Description: OpenPGP digital signature

Fix libgcj build failure on Alpha

[Andrew Haley]

write_barrier() is missing in the libgcj build.  Fixed thusly.

Andrew.


2007-01-22  Andrew Haley  <[EMAIL PROTECTED]>

* sysdep/alpha/locks.h (write_barrier): New.

Index: locks.h
===
--- locks.h (revision 120859)
+++ locks.h (working copy)
@@ -50,4 +50,12 @@
   return compare_and_swap(addr, old, new_val);
 }
 
+// Ensure that prior stores to memory are completed with respect to other
+// processors.
+inline static void
+write_barrier()
+{
+  __asm__ __volatile__("wmb" : : : "memory");
+}
+
 #endif

Re: raising minimum version of Flex

[Marcin Dalecki]

Wiadomość napisana w dniu 2007-01-22, o godz06:49, przez Ben Elliston:


I think it's worth raising the minimum required version from 2.5.4 to
2.5.31.  The latter version was released in March, 2003, so it is  
hardly

bleeding edge.


Your definition of bleeding edge doesn't fit mine:

$ flex --version
flex version 2.5.4
$ uname -a
Darwin xxx 8.8.0 Darwin Kernel Version 8.8.0: Fri Sep  8 17:18:57 PDT  
2006; root:xnu-792.12.6.obj~1/RELEASE_PPC Power Macintosh powerpc


∎ Marcin Dalecki ∎

Signed int overflow behaviour in the security context

[Andreas Bogk]

Dear compiler hackers,

I feel compelled to revisit a topic that has already been extensively
discussed on this mailing list, unfortunately with an outcome that is
highly dangerous to the security of about any existing system compiled
with gcc in the world.

It is my fear that the existing behaviour of gcc when used without
-fwrapv breaks a lot of code out there that was written with the
implicit assumption that signed ints would overflow the way the
underlying machine integers do.  More importantly, some of the code that
breaks is in checks against integer overflows, and thus relevant to
security: breaking the checks means opening vulnerabilities.  A number
of IT security professionals shares my view of things here.

I am well aware that the current behaviour of gcc is within what is
allowed by the C standard.  I am also aware that writing code depending
on a certain type of signed overflow behaviour is not.  However, there
are tens of millions lines of code out there written with this
assumption, and a comparatively simple change to gcc would prevent a
whole class of security problems in just about any Linux and BSD box out
there.

Auditing all this existing code out there for this specific
vulnerability is just hopeless, fixing it in gcc is the only right thing
to do.  And the fix would be LIA-1 compliant overflow behaviour.

A point that was often raised against making -fwrapv behaviour the
default was performance issues.  But neither reading the existing
thread, nor extensive discussion in the context of bug report 30475
showed benchmarks backing this argument, or any kind of theoretic
argument why breaking signedness overflow behaviour actually helps in
any optimization.

I then did some code reading, again see bug 30475.  And it turns out
that -fwrapv is implemented in a way that actually makes the reader
afraid that it does hurt performance.  As an example, the optimization
that is hurting us in the security context is folding of comparisons
based on integer range analysis.  The code for generating ranges
(fold-const.c, make_range()) for instance won't generate ranges that
properly respect overflow behaviour of signed ints.  Now instead of
fixing this, and generating proper ranges for signed ints when -fwrapv
is passed, the code continues to generate broken ranges, but turns off
all downstream optimizations depending on ranges if the expression is
signed.

There is a clear way to fix the performance issues of -fwrapv and still
make signed int overflow do the right thing.  I would like to appeal to
the gcc developers and the Steering Board to re-visit their position on
the issue, and take the route of making -fwrapv the default, and then
re-engineering it to do the right thing performance-wise.

Best regards,
Andreas

Re: Getting a tree node for a field of a variable

[Ferad Zyulkyarov]

typedef struct MyType
{
  int field1;
  int field2;
}

MyType *var;


Finally, I found a way to get the tree node for "var->field1" assuming
that we compile the code above. Here is an example:

tree var_decl = lookup_name(get_identifier("var"));
tree var_field1 = build_component_ref(build_indirect_ref(var_decl,
"var"), get_identifier("field1"));

"var_field1" is the "var->field1" tree node.


--
Ferad Zyulkyarov
Barcelona Supercomputing Center

Re: raising minimum version of Flex

[Tom Tromey]

> "Ian" == Ian Lance Taylor <[EMAIL PROTECTED]> writes:

Ben> I think it's worth raising the minimum required version from 2.5.4 to
Ben> 2.5.31.

Ian> I want to point out that Fedora Core 5 appears to still ship flex
Ian> 2.5.4.  At least, that is what flex --version reports.

When this came up on irc, I looked around a little.  I think flex will
be upgraded in Fedora 7.

It would not be outrageously hard to set up a yum repository that
serves updated flex and gmp (+mpfr) RPMs, for GCC developers to use.

Tom

Re: raising minimum version of Flex

[Joseph S. Myers]

On Mon, 22 Jan 2007, Ben Elliston wrote:

> I submitted a patch to gengtype-lex.l last week to gcc-patches.  The
> patch uses some flex %option directives.  Ian Taylor asked me to check
> if the patch passed through flex 2.5.4, which is the current minimum
> required version.  It didn't work.
> 
> Through some experimentation, I learned that the minimum version of Flex
> that did accept my patch was 2.5.31.  The effect of the patch is that it
> eliminates around ten warnings from the build.
> 
> I think it's worth raising the minimum required version from 2.5.4 to
> 2.5.31.  The latter version was released in March, 2003, so it is hardly
> bleeding edge.  Mike Stump commented that so few developers actually
> need flex for development work, that it will represent a very small
> inconvenience.  Moreover, users get the generated C code in their GCC
> releases, so they never have to install flew anyway.
> 
> Thoughts?

I'm not at all impressed with the recent series of flex releases, since it 
started using m4 internally and passing user code through m4.  This 
created a whole series of bugs and piles of patches distributions needed 
to apply with scanners conforming to the POSIX lex definition being 
mangled.  The manual in flex 2.5.33 suggests that this class of bug is 
still present and certain arbitrary non-POSIX restrictions are being 
applied to user scanners, and I don't think distribution patches 
completely fix this.  flex needs more attention paid to POSIX and 
backwards compatibility to clean up this mess (cf. bison, which unlike 
flex pays proper attention to assuring that arbitrary valid parsers are 
not mangled by m4).

Perhaps the various distributions people have noted still using 2.5.4 are 
equally unimpressed by the approach of recent flex releases to correctness 
and compatibility.

-- 
Joseph S. Myers
[EMAIL PROTECTED]

Re: Signed int overflow behaviour in the security context

[Ian Lance Taylor]

Andreas Bogk <[EMAIL PROTECTED]> writes:

> It is my fear that the existing behaviour of gcc when used without
> -fwrapv breaks a lot of code out there that was written with the
> implicit assumption that signed ints would overflow the way the
> underlying machine integers do.  More importantly, some of the code that
> breaks is in checks against integer overflows, and thus relevant to
> security: breaking the checks means opening vulnerabilities.  A number
> of IT security professionals shares my view of things here.

I am not interested in starting another lengthy discussion on this
general issue.

I just want to report that I have a working patch to generate warnings
every time gcc modifies code relying on the fact that signed overflow
is undefined, except for cases where signed loop indexes are assumed
to not wrap around.  I plan to start submitting this patch soon.

My current intention, subject of course to the opinions of other
maintainers, is to implement a -fstrict-overflow option, along the
lines of -fstrict-aliasing.  This will be enabled by default at -O2,
as is the case for -fstrict-aliasing.  -fno-strict-overflow will not
be the same as -fwrapv, but it will inhibit optimizations which are
only valid if signed overflow is undefined.  The new -Wstrict-overflow
warning will issue warnings for each case where gcc assumes that
signed overflow is undefined.

To be clear, this -Wstrict-overflow option generates a lot of false
positives.  That is because there are a lot of cases where gcc will
optimize code in ways that would fail if the numbers involved were
close to INT_MAX or INT_MIN.  For example, when compiling the gcc/*.c
files, I get 62 warnings.

I would appreciate any comments about this plan.


Some comments about those 62 warnings.  First, each one of those
warnings is a case where gcc implemented an optimization which could
not have been implemented when using -fwrapv.  Now, a couple of
examples.

In bb-reorder.c at line 266 we find this:

  find_traces_1_round (REG_BR_PROB_BASE * branch_threshold[i] / 1000,
   max_entry_frequency * exec_threshold[i] / 1000,
   count_threshold, traces, n_traces, i, &heap,
   number_of_rounds);

REG_BR_PROB_BASE is a #define macro with the value 1.  gcc
converts (1 * branch_threshold[i] / 1000) into (10 *
branch_threshold[i]).  This minor optimization is only possible
because signed overflow is undefined.  If branch_threshold[i] had the
value (INT_MAX / 10 - 1), say, the optimization will cause the
expression to have a different result (assuming standards
twos-complement arithmetic wrapping).  I see 17 warnings of this
form.

In expmed.c we find several times (size - 1 < BITS_PER_WORD).  gcc
converts this to (size <= BITS_PER_WORD).  This optimization is only
possible because signed overflow is undefined.  If size has the value
INT_MIN, the optimization will cause the expression to have a
different result.  I see 23 warnings of this form.

In fact, all the warnings on gcc/*.c have the same general form: a
mathematical simplification which is only permissible if the values do
not wrap around.

Ian

Gcc-4.1.1: Build error for arm-target

[Thomas Meyer]

Hello.

I try to build a cross compiler for this target: arm-uclinux-uclibc:

First the build fails because of a wrong config entry in config.gcc:

This should fix this:

diff --git a/gcc/config.gcc b/gcc/config.gcc
index 033cc3d..378a92d 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -691,7 +691,7 @@ arm*-*-linux*)# ARM GNU/Linux with ELF
tm_file="$tm_file arm/aout.h arm/arm.h"
;;
arm*-*-uclinux*)# ARM ucLinux
-tm_file="dbxelf.h elfos.h arm/unknown-elf.h arm/elf.h arm/aout.h 
arm/arm.h arm/linux-gas.h arm/linux-elf.h arm/uclinux-elf.h"
+tm_file="dbxelf.h elfos.h arm/unknown-elf.h arm/elf.h arm/aout.h 
arm/arm.h arm/linux-gas.h arm/uclinux-elf.h"

tmake_file="arm/t-arm arm/t-arm-elf"
;;
arm*-*-ecos-elf)


Compile continues here but then i  get this error likley while building 
libgcc2 (clear_cache):


/home/thomas/source/buildgcc/./gcc/xgcc 
-B/home/thomas/source/buildgcc/./gcc/ -B/usr/arm-uclinux-uclibc/bin/ 
-B/usr/arm-uclinux-uclibc/lib/ -isystem /usr/arm-uclinux-uclibc/include 
-isystem /usr/arm-uclinux-uclibc/sys-include -O2  -g -Os -DIN_GCC 
-DCROSS_COMPILE   -W -Wall -Wwrite-strings -Wstrict-prototypes 
-Wmissing-prototypes -Wold-style-definition  -isystem ./include  
-Dinhibit_libc -fno-inline -g  -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED 
-Dinhibit_libc -I. -I. -I../../gcc-4.1.1/gcc -I../../gcc-4.1.1/gcc/. 
-I../../gcc-4.1.1/gcc/../include 
-I../../gcc-4.1.1/gcc/../libcpp/include  -mthumb -DL_clear_cache -c 
../../gcc-4.1.1/gcc/libgcc2.c -o libgcc/thumb/_clear_cache.o

In file included from ./tm.h:13,
from ../../gcc-4.1.1/gcc/libgcc2.c:35:
../../gcc-4.1.1/gcc/config/arm/uclinux-elf.h:68:1: warning: 
"LINK_GCC_C_SEQUENCE_SPEC" redefined

In file included from ./tm.h:8,
from ../../gcc-4.1.1/gcc/libgcc2.c:35:
../../gcc-4.1.1/gcc/config/arm/unknown-elf.h:97:1: warning: this is the 
location of the previous definition

/tmp/ccnrn9Ag.s: Assembler messages:
/tmp/ccnrn9Ag.s:26: Error: invalid swi expression
/tmp/ccnrn9Ag.s:26: Error: value of 009f0002 too large for field 
of 2 bytes at 0002

make[3]: *** [libgcc/thumb/_clear_cache.o] Fehler 1
make[3]: Leaving directory `/home/thomas/source/buildgcc/gcc'
make[2]: *** [stmp-multilib] Fehler 2
make[2]: Leaving directory `/home/thomas/source/buildgcc/gcc'
make[1]: *** [all-gcc] Fehler 2
make[1]: Leaving directory `/home/thomas/source/buildgcc'
make: *** [all] Fehler 2

Any ideas?

--
Jabber-ID: [EMAIL PROTECTED]

The Linux binutils 2.17.50.0.10 is released

[H. J. Lu]

This is the beta release of binutils 2.17.50.0.10 for Linux, which is
based on binutils 2007 0122 in CVS on sourceware.org plus various
changes. It is purely for Linux.

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.17.50.0.10 to [EMAIL PROTECTED]

and

http://www.sourceware.org/bugzilla/

Changes from binutils 2.17.50.0.9:

1. Update from binutils 2007 0122.
2. Implement sharable section proposal for ia32, x86-64 and ia64:

http://groups-beta.google.com/group/generic-abi

3. Implement linker enhancement, -Bsymbolic-functions,
--dynamic-list-cpp-new and --dynamic-list-data.  PR 3831.
4. Implement new linker switch, --default-script=FILE/-dT FILE.
5. Fix x86 assembler error message. PR 3830.
6. Fix a bug in ld testsuite.  PR 1283.
7. Don't include archive64.o for 32bit target.  PR 3631.
8. Support -z max-page-size and -z common-page-size in user provided
linker script.
9. Fix 32bit library support for GNU/kFreeBSD/x86-64.  PR 3843.
10. Fix some bugs in Score assembler. PR 3871.
11. Fix various bugs in ARM assembler. PR 3707 and more.
12. Add Fido support.

Changes from binutils 2.17.50.0.8:

1. Update from binutils 2007 0103.
2. Fix --wrap linker bug.
3. Improve handling ELF binaries generated by foreign ELF linkers.
4. Various ELF M68K bug fixes.
5. Score bug fixes.
6. Don't read past end of archive elements. PR 3704.
7. Improve .eh_frame_hdr section handling.
8. Fix symbol visibility with comdat/linkonce sections in ELF linker.
PR 3666.
9. Fix 4 operand instruction handling in x86 assembler.
10. Properly check the 4th operand in x86 assembler. PR 3712.
11. Fix .cfi_endproc handling in assembler. PR 3607.
12. Various ARM bug fixes.
13. Various PE linker fixes.
14. Improve x86 dissassembler for cmpxchg16b.

Changes from binutils 2.17.50.0.7:

1. Update from binutils 2006 1201.
2. Fix "objcopy --only-keep-debug" crash. PR 3609.
3. Fix various ARM ELF bugs.
4. Fix various xtensa bugs.
5. Update x86 disassembler.

Changes from binutils 2.17.50.0.6:

1. Update from binutils 2006 1127.
2. Properly set ELF output segment address when the first section in
input segment is removed.
3. Better merging of CIEs in linker .eh_frame optimizations.
4. Support .cfi_personality and .cfi_lsda assembler directives.
5. Fix an ARM linker crash. PR 3532.
6. Fix various PPC64 ELF bugs.
7. Mark discarded debug info more thoroughly in linker output.
8. Fix various MIPS ELF bugs.
9. Fix readelf to display program interpreter path > 64 chars. PR 3384.
10. Add support for PowerPC SPU.
11. Properly handle cloned symbols used in relocations in assembler. PR
3469.
12. Update opcode for POPCNT in amdfam10 architecture.

Changes from binutils 2.17.50.0.5:

1. Update from binutils 2006 1020.
2. Don't make debug symbol dynamic. PR 3290.
3. Don't page align empty SHF_ALLOC sections, which l

Re: Signed int overflow behaviour in the security context

[Joe Buck]

On Mon, Jan 22, 2007 at 11:16:06AM -0800, Ian Lance Taylor wrote:
>   The new -Wstrict-overflow
> warning will issue warnings for each case where gcc assumes that
> signed overflow is undefined.
> 
> To be clear, this -Wstrict-overflow option generates a lot of false
> positives.  That is because there are a lot of cases where gcc will
> optimize code in ways that would fail if the numbers involved were
> close to INT_MAX or INT_MIN.  For example, when compiling the gcc/*.c
> files, I get 62 warnings. ...
> 
> Some comments about those 62 warnings.  First, each one of those
> warnings is a case where gcc implemented an optimization which could
> not have been implemented when using -fwrapv.  Now, a couple of
> examples.
> 
> In bb-reorder.c at line 266 we find this:
> 
>   find_traces_1_round (REG_BR_PROB_BASE * branch_threshold[i] / 1000,
>  max_entry_frequency * exec_threshold[i] / 1000,
>  count_threshold, traces, n_traces, i, &heap,
>  number_of_rounds);
> 
> REG_BR_PROB_BASE is a #define macro with the value 1.  gcc
> converts (1 * branch_threshold[i] / 1000) into (10 *
> branch_threshold[i]).  This minor optimization is only possible
> because signed overflow is undefined.  If branch_threshold[i] had the
> value (INT_MAX / 10 - 1), say, the optimization will cause the
> expression to have a different result (assuming standards
> twos-complement arithmetic wrapping).  I see 17 warnings of this
> form.
> 
> In expmed.c we find several times (size - 1 < BITS_PER_WORD).  gcc
> converts this to (size <= BITS_PER_WORD).  This optimization is only
> possible because signed overflow is undefined.

Here's a thought: assuming we can ignore overflow is equivalent to
assuming that we have more information about the range of a variable
than is provided by the value.  What if the other proposal we say
recently, for assume(), were added?  e.g.

  assume (size < INT_MAX);
  assume (branch_threshold[i] < INT_MAX / 1);

Re: Gcc-4.1.1: Build error for arm-target

[Thomas Meyer]

Thomas Meyer schrieb:

Hello.

I try to build a cross compiler for this target: arm-uclinux-uclibc:

First the build fails because of a wrong config entry in config.gcc:

This should fix this:

diff --git a/gcc/config.gcc b/gcc/config.gcc
index 033cc3d..378a92d 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -691,7 +691,7 @@ arm*-*-linux*)# ARM GNU/Linux with ELF
tm_file="$tm_file arm/aout.h arm/arm.h"
;;
arm*-*-uclinux*)# ARM ucLinux
-tm_file="dbxelf.h elfos.h arm/unknown-elf.h arm/elf.h arm/aout.h 
arm/arm.h arm/linux-gas.h arm/linux-elf.h arm/uclinux-elf.h"
+tm_file="dbxelf.h elfos.h arm/unknown-elf.h arm/elf.h arm/aout.h 
arm/arm.h arm/linux-gas.h arm/uclinux-elf.h"

tmake_file="arm/t-arm arm/t-arm-elf"
;;
arm*-*-ecos-elf)


Compile continues here but then i  get this error likley while 
building libgcc2 (clear_cache):


/home/thomas/source/buildgcc/./gcc/xgcc 
-B/home/thomas/source/buildgcc/./gcc/ -B/usr/arm-uclinux-uclibc/bin/ 
-B/usr/arm-uclinux-uclibc/lib/ -isystem 
/usr/arm-uclinux-uclibc/include -isystem 
/usr/arm-uclinux-uclibc/sys-include -O2  -g -Os -DIN_GCC 
-DCROSS_COMPILE   -W -Wall -Wwrite-strings -Wstrict-prototypes 
-Wmissing-prototypes -Wold-style-definition  -isystem ./include  
-Dinhibit_libc -fno-inline -g  -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED 
-Dinhibit_libc -I. -I. -I../../gcc-4.1.1/gcc -I../../gcc-4.1.1/gcc/. 
-I../../gcc-4.1.1/gcc/../include 
-I../../gcc-4.1.1/gcc/../libcpp/include  -mthumb -DL_clear_cache -c 
../../gcc-4.1.1/gcc/libgcc2.c -o libgcc/thumb/_clear_cache.o

In file included from ./tm.h:13,
from ../../gcc-4.1.1/gcc/libgcc2.c:35:
../../gcc-4.1.1/gcc/config/arm/uclinux-elf.h:68:1: warning: 
"LINK_GCC_C_SEQUENCE_SPEC" redefined

In file included from ./tm.h:8,
from ../../gcc-4.1.1/gcc/libgcc2.c:35:
../../gcc-4.1.1/gcc/config/arm/unknown-elf.h:97:1: warning: this is 
the location of the previous definition

/tmp/ccnrn9Ag.s: Assembler messages:
/tmp/ccnrn9Ag.s:26: Error: invalid swi expression
/tmp/ccnrn9Ag.s:26: Error: value of 009f0002 too large for 
field of 2 bytes at 0002

make[3]: *** [libgcc/thumb/_clear_cache.o] Fehler 1
make[3]: Leaving directory `/home/thomas/source/buildgcc/gcc'
make[2]: *** [stmp-multilib] Fehler 2
make[2]: Leaving directory `/home/thomas/source/buildgcc/gcc'
make[1]: *** [all-gcc] Fehler 2
make[1]: Leaving directory `/home/thomas/source/buildgcc'
make: *** [all] Fehler 2

Any ideas?


Here is the created assembler code:

   .code16
   .file"libgcc2.c"
   .section.debug_abbrev,"",%progbits
.Ldebug_abbrev0:
   .section.debug_info,"",%progbits
.Ldebug_info0:
   .section.debug_line,"",%progbits
.Ldebug_line0:
   .text
.Ltext0:
   .align2
   .global__clear_cache
   .code 16
   .thumb_func
   .type__clear_cache, %function
__clear_cache:
.LFB2:
   .file 1 "../../gcc-4.1.1/gcc/libgcc2.c"
   .loc 1 1814 0
.LVL0:
   @ lr needed for prologue
.LBB2:
   .loc 1 1816 0
   movr2, #0
.LVL1:
   swi 0x9f0002@ sys_cacheflush
   .code16
.LBE2:
   .loc 1 1818 0
   @ sp needed for prologue
   bxlr


Rhe swi call seems to be ok for linux. I'm not sure why the xgcc doesn't 
seem to like this instruction.

Re: Gcc-4.1.1: Build error for arm-target

[Thomas Meyer]

Thomas Meyer schrieb:

Thomas Meyer schrieb:

Hello.

I try to build a cross compiler for this target: arm-uclinux-uclibc:

First the build fails because of a wrong config entry in config.gcc:

This should fix this:

diff --git a/gcc/config.gcc b/gcc/config.gcc
index 033cc3d..378a92d 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -691,7 +691,7 @@ arm*-*-linux*)# ARM GNU/Linux with ELF
tm_file="$tm_file arm/aout.h arm/arm.h"
;;
arm*-*-uclinux*)# ARM ucLinux
-tm_file="dbxelf.h elfos.h arm/unknown-elf.h arm/elf.h arm/aout.h 
arm/arm.h arm/linux-gas.h arm/linux-elf.h arm/uclinux-elf.h"
+tm_file="dbxelf.h elfos.h arm/unknown-elf.h arm/elf.h arm/aout.h 
arm/arm.h arm/linux-gas.h arm/uclinux-elf.h"

tmake_file="arm/t-arm arm/t-arm-elf"
;;
arm*-*-ecos-elf)


Compile continues here but then i  get this error likley while 
building libgcc2 (clear_cache):


/home/thomas/source/buildgcc/./gcc/xgcc 
-B/home/thomas/source/buildgcc/./gcc/ -B/usr/arm-uclinux-uclibc/bin/ 
-B/usr/arm-uclinux-uclibc/lib/ -isystem 
/usr/arm-uclinux-uclibc/include -isystem 
/usr/arm-uclinux-uclibc/sys-include -O2  -g -Os -DIN_GCC 
-DCROSS_COMPILE   -W -Wall -Wwrite-strings -Wstrict-prototypes 
-Wmissing-prototypes -Wold-style-definition  -isystem ./include  
-Dinhibit_libc -fno-inline -g  -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED 
-Dinhibit_libc -I. -I. -I../../gcc-4.1.1/gcc -I../../gcc-4.1.1/gcc/. 
-I../../gcc-4.1.1/gcc/../include 
-I../../gcc-4.1.1/gcc/../libcpp/include  -mthumb -DL_clear_cache -c 
../../gcc-4.1.1/gcc/libgcc2.c -o libgcc/thumb/_clear_cache.o

In file included from ./tm.h:13,
from ../../gcc-4.1.1/gcc/libgcc2.c:35:
../../gcc-4.1.1/gcc/config/arm/uclinux-elf.h:68:1: warning: 
"LINK_GCC_C_SEQUENCE_SPEC" redefined

In file included from ./tm.h:8,
from ../../gcc-4.1.1/gcc/libgcc2.c:35:
../../gcc-4.1.1/gcc/config/arm/unknown-elf.h:97:1: warning: this is 
the location of the previous definition

/tmp/ccnrn9Ag.s: Assembler messages:
/tmp/ccnrn9Ag.s:26: Error: invalid swi expression
/tmp/ccnrn9Ag.s:26: Error: value of 009f0002 too large for 
field of 2 bytes at 0002

make[3]: *** [libgcc/thumb/_clear_cache.o] Fehler 1
make[3]: Leaving directory `/home/thomas/source/buildgcc/gcc'
make[2]: *** [stmp-multilib] Fehler 2
make[2]: Leaving directory `/home/thomas/source/buildgcc/gcc'
make[1]: *** [all-gcc] Fehler 2
make[1]: Leaving directory `/home/thomas/source/buildgcc'
make: *** [all] Fehler 2

Any ideas?


Here is the created assembler code:

   .code16
   .file"libgcc2.c"
   .section.debug_abbrev,"",%progbits
.Ldebug_abbrev0:
   .section.debug_info,"",%progbits
.Ldebug_info0:
   .section.debug_line,"",%progbits
.Ldebug_line0:
   .text
.Ltext0:
   .align2
   .global__clear_cache
   .code 16
   .thumb_func
   .type__clear_cache, %function
__clear_cache:
.LFB2:
   .file 1 "../../gcc-4.1.1/gcc/libgcc2.c"
   .loc 1 1814 0
.LVL0:
   @ lr needed for prologue
.LBB2:
   .loc 1 1816 0
   movr2, #0
.LVL1:
   swi 0x9f0002@ sys_cacheflush
   .code16
.LBE2:
   .loc 1 1818 0
   @ sp needed for prologue
   bxlr


Rhe swi call seems to be ok for linux. I'm not sure why the xgcc 
doesn't seem to like this instruction.





Ah! Now i understand: The binutils-as seems to be called from gcc, this 
programs throws the original error:


./arm-uclinux-uclibc-as libgcc2.s
libgcc2.s: Assembler messages:
libgcc2.s:26: Error: invalid swi expression
libgcc2.s:26: Error: value of 009f0002 too large for field of 2 
bytes at 0002


So this is maybe an error in my binutils version, that is 2.17?

Re: Gcc-4.1.1: Build error for arm-target

[Thomas Meyer]

Thomas Meyer schrieb:

Thomas Meyer schrieb:

Thomas Meyer schrieb:

Hello.

I try to build a cross compiler for this target: arm-uclinux-uclibc:

First the build fails because of a wrong config entry in config.gcc:

This should fix this:

diff --git a/gcc/config.gcc b/gcc/config.gcc
index 033cc3d..378a92d 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -691,7 +691,7 @@ arm*-*-linux*)# ARM GNU/Linux with ELF
tm_file="$tm_file arm/aout.h arm/arm.h"
;;
arm*-*-uclinux*)# ARM ucLinux
-tm_file="dbxelf.h elfos.h arm/unknown-elf.h arm/elf.h 
arm/aout.h arm/arm.h arm/linux-gas.h arm/linux-elf.h arm/uclinux-elf.h"
+tm_file="dbxelf.h elfos.h arm/unknown-elf.h arm/elf.h 
arm/aout.h arm/arm.h arm/linux-gas.h arm/uclinux-elf.h"

tmake_file="arm/t-arm arm/t-arm-elf"
;;
arm*-*-ecos-elf)


Compile continues here but then i  get this error likley while 
building libgcc2 (clear_cache):


/home/thomas/source/buildgcc/./gcc/xgcc 
-B/home/thomas/source/buildgcc/./gcc/ -B/usr/arm-uclinux-uclibc/bin/ 
-B/usr/arm-uclinux-uclibc/lib/ -isystem 
/usr/arm-uclinux-uclibc/include -isystem 
/usr/arm-uclinux-uclibc/sys-include -O2  -g -Os -DIN_GCC 
-DCROSS_COMPILE   -W -Wall -Wwrite-strings -Wstrict-prototypes 
-Wmissing-prototypes -Wold-style-definition  -isystem ./include  
-Dinhibit_libc -fno-inline -g  -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED 
-Dinhibit_libc -I. -I. -I../../gcc-4.1.1/gcc -I../../gcc-4.1.1/gcc/. 
-I../../gcc-4.1.1/gcc/../include 
-I../../gcc-4.1.1/gcc/../libcpp/include  -mthumb -DL_clear_cache -c 
../../gcc-4.1.1/gcc/libgcc2.c -o libgcc/thumb/_clear_cache.o

In file included from ./tm.h:13,
from ../../gcc-4.1.1/gcc/libgcc2.c:35:
../../gcc-4.1.1/gcc/config/arm/uclinux-elf.h:68:1: warning: 
"LINK_GCC_C_SEQUENCE_SPEC" redefined

In file included from ./tm.h:8,
from ../../gcc-4.1.1/gcc/libgcc2.c:35:
../../gcc-4.1.1/gcc/config/arm/unknown-elf.h:97:1: warning: this is 
the location of the previous definition

/tmp/ccnrn9Ag.s: Assembler messages:
/tmp/ccnrn9Ag.s:26: Error: invalid swi expression
/tmp/ccnrn9Ag.s:26: Error: value of 009f0002 too large for 
field of 2 bytes at 0002

make[3]: *** [libgcc/thumb/_clear_cache.o] Fehler 1
make[3]: Leaving directory `/home/thomas/source/buildgcc/gcc'
make[2]: *** [stmp-multilib] Fehler 2
make[2]: Leaving directory `/home/thomas/source/buildgcc/gcc'
make[1]: *** [all-gcc] Fehler 2
make[1]: Leaving directory `/home/thomas/source/buildgcc'
make: *** [all] Fehler 2

Any ideas?


Here is the created assembler code:

   .code16
   .file"libgcc2.c"
   .section.debug_abbrev,"",%progbits
.Ldebug_abbrev0:
   .section.debug_info,"",%progbits
.Ldebug_info0:
   .section.debug_line,"",%progbits
.Ldebug_line0:
   .text
.Ltext0:
   .align2
   .global__clear_cache
   .code 16
   .thumb_func
   .type__clear_cache, %function
__clear_cache:
.LFB2:
   .file 1 "../../gcc-4.1.1/gcc/libgcc2.c"
   .loc 1 1814 0
.LVL0:
   @ lr needed for prologue
.LBB2:
   .loc 1 1816 0
   movr2, #0
.LVL1:
   swi 0x9f0002@ sys_cacheflush
   .code16
.LBE2:
   .loc 1 1818 0
   @ sp needed for prologue
   bxlr


Rhe swi call seems to be ok for linux. I'm not sure why the xgcc 
doesn't seem to like this instruction.





Ah! Now i understand: The binutils-as seems to be called from gcc, 
this programs throws the original error:


./arm-uclinux-uclibc-as libgcc2.s
libgcc2.s: Assembler messages:
libgcc2.s:26: Error: invalid swi expression
libgcc2.s:26: Error: value of 009f0002 too large for field of 
2 bytes at 0002


So this is maybe an error in my binutils version, that is 2.17?



Ok. This is not an error in binutils as. The code is .code 16, so this 
should run in thumb mode, which is obviuosly wrong (uclinux seems also 
to use these system call vectors and runs in arm mode and not thumb 
mode, doesn't it?!) so also define multilib_defaults like in linux-elf.h:


diff --git a/gcc/config.gcc b/gcc/config.gcc
index 033cc3d..378a92d 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -691,7 +691,7 @@ arm*-*-linux*)# ARM GNU/Linux with ELF
tm_file="$tm_file arm/aout.h arm/arm.h"
;;
arm*-*-uclinux*)# ARM ucLinux
-tm_file="dbxelf.h elfos.h arm/unknown-elf.h arm/elf.h arm/aout.h 
arm/arm.h arm/linux-gas.h arm/linux-elf.h arm/uclinux-elf.h"
+tm_file="dbxelf.h elfos.h arm/unknown-elf.h arm/elf.h arm/aout.h 
arm/arm.h arm/linux-gas.h arm/uclinux-elf.h"

tmake_file="arm/t-arm arm/t-arm-elf"
;;
arm*-*-ecos-elf)

diff --git a/gcc/config/arm/uclinux-elf.h b/gcc/config/arm/uclinux-elf.h
index 9f112cd..8c5fd7d 100644
--- a/gcc/config/arm/uclinux-elf.h
+++ b/gcc/config/arm/uclinux-elf.h
@@ -72,3 +72,7 @@
#ifdef HAVE_LD_AS_NEEDED
#define USE_LD_AS_NEEDED 1
#endif
+
+#undef  MULTILIB_DEFAULTS
+#define MULTILIB_DEFAULTS \
+{ "marm", "mlittle-endian", "mhard-float", "mno-thumb-interwork" }

Please someone comment this!

With kind 

gcc-4.1-20070122 is now available

[gccadmin]

Snapshot gcc-4.1-20070122 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20070122/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 4.1 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_1-branch 
revision 121063

You'll find:

gcc-4.1-20070122.tar.bz2  Complete GCC (includes all of below)

gcc-core-4.1-20070122.tar.bz2 C front end and core compiler

gcc-ada-4.1-20070122.tar.bz2  Ada front end and runtime

gcc-fortran-4.1-20070122.tar.bz2  Fortran front end and runtime

gcc-g++-4.1-20070122.tar.bz2  C++ front end and runtime

gcc-java-4.1-20070122.tar.bz2 Java front end and runtime

gcc-objc-4.1-20070122.tar.bz2 Objective-C front end and runtime

gcc-testsuite-4.1-20070122.tar.bz2The GCC testsuite

Diffs from 4.1-20070115 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.1
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Re: raising minimum version of Flex

[Ben Elliston]

Thanks all for the discussion.  I think we can conclude that it's not
safe to require a newer version of Flex.  I withdraw my patch.

Cheers, Ben

Re: raising minimum version of Flex

[Mike Stump]

On Jan 21, 2007, at 11:48 PM, Ian Lance Taylor wrote:

That doesn't sound right.  It see flex being run every time I create a
new object directory, even though I don't modify the flex input files.


Sounds like a bug.  I did a quick check with a contrib/gcc_update -- 
touch and a c,treelang build and sure enough, flex is run 5 times, so,  
unless this bug is fixed, everyone that has an older flex will get  
build errors.  :-(  I think this bug should be fixed before we update  
the minimum version requirements for flex.  If it was, I'd support  
updating the min version required.

Re: Signed int overflow behaviour in the security context

[Andreas Bogk]

Ian Lance Taylor wrote:
> I just want to report that I have a working patch to generate warnings
> every time gcc modifies code relying on the fact that signed overflow
> is undefined, except for cases where signed loop indexes are assumed
> to not wrap around.  I plan to start submitting this patch soon.

Having that would be a useful tool for the scurity folks to have, to go
out and assess the threat that really lurks in the code out there.  My
gut feeling is that we will find quite some problems, in fact so many
that "secure by default" is an argument that will outweigh performance.
 I could be wrong though, maybe the number is so small that it is
feasible fo fix them all for the major applications.

Having numbers will hopefully keep the discussion reasonable.

I have by now been sent performance figures, somebody measured about
2-4% slowdown for the SPEC suite, for whatever that means for real-world
applications.  This is more than I had expected, but I think could be
improved upon.  If I understand it correctly, people might already be
working on performance improvements.

> My current intention, subject of course to the opinions of other
> maintainers, is to implement a -fstrict-overflow option, along the
> lines of -fstrict-aliasing.  This will be enabled by default at -O2,
> as is the case for -fstrict-aliasing.  -fno-strict-overflow will not
> be the same as -fwrapv, but it will inhibit optimizations which are
> only valid if signed overflow is undefined.  The new -Wstrict-overflow
> warning will issue warnings for each case where gcc assumes that
> signed overflow is undefined.

This sounds like a good approach.  I will defer the argument about
whether or not to make -fstrict-overflow the default to a time where we
have more information about the scope of the threat.

Regards,
Andreas

Re: Signed int overflow behaviour in the security context

[Joe Buck]

On Mon, Jan 22, 2007 at 06:48:16PM -0500, Andreas Bogk wrote:
> Ian Lance Taylor wrote:
> > I just want to report that I have a working patch to generate warnings
> > every time gcc modifies code relying on the fact that signed overflow
> > is undefined, except for cases where signed loop indexes are assumed
> > to not wrap around.  I plan to start submitting this patch soon.
> 
> Having that would be a useful tool for the scurity folks to have, to go
> out and assess the threat that really lurks in the code out there.  My
> gut feeling is that we will find quite some problems, in fact so many
> that "secure by default" is an argument that will outweigh performance.

You appear to mistakenly believe that wrapping around on overflow is a
more secure option.  It might be, but it usually is not.  There are many
CERT security flaws involving integer overflow; the fact that they are
security bugs has nothing to do with the way gcc generates code, as the
"wrapv" output is insecure.

AFAIK, "overflow doesn't occur" assumptions occur in currently shipping
compilers mainly in expression simplification (see previous examples in
this thread) and loop unrolling, and in either case application codes are
almost always written with a blithe assumption that overflow does not
occur.

Recent proposed changes to make value range propagation more aggressive do
look like they have the potential to tweak bugs, and it looks like those
changes aren't going to be enabled by default.

Re: Signed int overflow behaviour in the security context

[Andreas Bogk]

Joe Buck wrote:
> You appear to mistakenly believe that wrapping around on overflow is a
> more secure option.  It might be, but it usually is not.  There are many
> CERT security flaws involving integer overflow; the fact that they are
> security bugs has nothing to do with the way gcc generates code, as the
> "wrapv" output is insecure.

I am well aware of the fact that most intever overflows reported are a
case of the programmer completely ignoring the possibility of an
overflow.  What I'm afraid of is that there are probably enough
programmers out there clever enough to be aware of the fact that
overflow exists, but blindly assuming a defined semantics for them.

Of course the checks those people write are wrong.  But it is a
systematic bug that leads to exploitable situations in code.  The best
way from a security point of view to deal with the risk would be to
prevent the whole bug class from happening, by changing the compiler.

However, I also know that there is a certain tradeoff to be made, a cost
in performance for the case of default(!) optimizer settings.
-Wstrict-overflow will help making a call here.

> AFAIK, "overflow doesn't occur" assumptions occur in currently shipping
> compilers mainly in expression simplification (see previous examples in
> this thread) and loop unrolling, and in either case application codes are
> almost always written with a blithe assumption that overflow does not
> occur.

I must say I have a hard time creating an argument against the given
examples from a security point of view.  But there is no clear cut
between innocent and a vulnerability waiting to be discovered, undefined
semantics can always lead to subtle bugs.

The case is clear when an if branch is folded away, because some
comparison is folded that would not have been under twos-complement
semantics.  This is a pattern that probably doesn't happen all that much
in code out there, except in post-facto overflow checking.

Regards,
Andreas

Re: raising minimum version of Flex

[Ben Elliston]

On Mon, 2007-01-22 at 15:39 -0800, Mike Stump wrote:
> On Jan 21, 2007, at 11:48 PM, Ian Lance Taylor wrote:
> > That doesn't sound right.  It see flex being run every time I create a
> > new object directory, even though I don't modify the flex input files.
> 
> Sounds like a bug.  I did a quick check with a contrib/gcc_update -- 
> touch and a c,treelang build and sure enough, flex is run 5 times, so,  
> unless this bug is fixed, everyone that has an older flex will get  
> build errors.  :-(  I think this bug should be fixed before we update  
> the minimum version requirements for flex.  If it was, I'd support  
> updating the min version required.

gcc_update's touch commands don't help, do they?  I thought that the
Subversion repository did not even contain gengtype-lex.c and that flex
is *always* required for developer builds?

Ben

Re: Signed int overflow behaviour in the security context

[Ian Lance Taylor]

Andreas Bogk <[EMAIL PROTECTED]> writes:

> The case is clear when an if branch is folded away, because some
> comparison is folded that would not have been under twos-complement
> semantics.  This is a pattern that probably doesn't happen all that much
> in code out there, except in post-facto overflow checking.

Unfortunately this happens quite a lot.

Consider code along these lines:

struct s { int len; char* p; };

inline char
bar (struct s *sp, int n)
{
  if (n < 0)
abort ();
  if (n > sp->len)
abort ();
  return sp->p[n];
}

void
foo (struct s *sp, int n)
{
  int len = sp->len;
  int i;
  int tot = 0;
  for (i = 0; i <= len; ++i)
tot += bar (sp, i);
  return tot;
}

Let's assume that bar() is inlined into foo().  Now consider the
assert.  If signed overflow is undefined, then we can optimize away
the "n < 0" test; it will never be true.  If signed overflow is
defined, then we can not optimize that away.  That is because as far
as the compiler knows, sp->len might be INT_MAX.  In that case, the
loop will never terminate, and i will wrap and become negative.  (The
compiler may also eliminate the "n > sp->len" test, but that does not
rely on undefined signed overflow.)

This is a typical example of removing an if branch because signed
overflow is undefined.  This kind of code is common enough.

Ian