Fwd: avr-gcc (compiled from trunk) not placing objects in attributed sections in some cases.
all -Wextra -Werror -std=gnu99 -DMAKE_A_PROBLEM=1 -DMAKE_IT_WORK=1 -c -o gcc-data-sections.o gcc-data-sections.c $ avr-objdump -h gcc-data-sections.o gcc-data-sections.o: file format elf32-avr Sections: Idx Name Size VMA LMA File off Algn 0 .text 0034 2**0 CONTENTS, ALLOC, LOAD, READONLY, CODE 1 .data 0034 2**0 CONTENTS, ALLOC, LOAD, DATA 2 .bss 0034 2**0 ALLOC 3 .text.my_dummy 0002 0034 2**0 CONTENTS, ALLOC, LOAD, READONLY, CODE 4 .my.tables.things.data 0004 0036 2**0 CONTENTS, ALLOC, LOAD, DATA 5 .debug_info 0067 003a 2**0 CONTENTS, RELOC, READONLY, DEBUGGING 6 .debug_abbrev 0060 00a1 2**0 CONTENTS, READONLY, DEBUGGING 7 .debug_aranges 0020 0101 2**0 CONTENTS, RELOC, READONLY, DEBUGGING 8 .debug_ranges 0010 0121 2**0 CONTENTS, RELOC, READONLY, DEBUGGING 9 .debug_line 0043 0131 2**0 CONTENTS, RELOC, READONLY, DEBUGGING 10 .debug_str00e7 0174 2**0 CONTENTS, READONLY, DEBUGGING 11 .comment 002b 025b 2**0 CONTENTS, READONLY 12 .debug_frame 0024 0288 2**2 CONTENTS, RELOC, READONLY, DEBUGGING The trunk version that I built (using also trunk binutils and trunk avr-libc) is: $ avr-gcc -v Using built-in specs. COLLECT_GCC=avr-gcc COLLECT_LTO_WRAPPER=/misc/apps/avr8/tools_002/libexec/gcc/avr/4.10.0/lto-wrapper Target: avr Configured with: /home/df/src/gcc-trunk/configure --prefix=/misc/apps/avr8/tools_002 --target=avr --enable-languages=c,c++ --with-gnu-as --with-gnu-ld --with-dwarf2 --with-avrlibc=yes --enable-fixed-point --enable-doc --disable-libssp --disable-libada --disable-shared -v Thread model: single gcc version 4.10.0 20140729 (experimental) (GCC) The atmel gcc is: $ avr-gcc -v Using built-in specs. COLLECT_GCC=avr-gcc COLLECT_LTO_WRAPPER=/misc/apps/avr8/avr8-gnu-toolchain-linux_x86_64/bin/../libexec/gcc/avr/4.8.1/lto-wrapper Target: avr Configured with: /data2/home/toolsbuild/jenkins-knuth/workspace/avr8-gnu-toolchain/src/gcc/configure LDFLAGS=-L/home/toolsbuild/jenkins-knuth/workspace/avr8-gnu-toolchain/avr8-gnu-toolchain-linux_x86_64/lib CPPFLAGS= --target=avr --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/home/toolsbuild/jenkins-knuth/workspace/avr8-gnu-toolchain/avr8-gnu-toolchain-linux_x86_64 --libdir=/home/toolsbuild/jenkins-knuth/workspace/avr8-gnu-toolchain/avr8-gnu-toolchain-linux_x86_64/lib --enable-languages=c,c++ --with-dwarf2 --enable-doc --disable-shared --disable-libada --disable-libssp --disable-nls --with-avrlibc=yes --with-mpfr=/home/toolsbuild/jenkins-knuth/workspace/avr8-gnu-toolchain/avr8-gnu-toolchain-linux_x86_64 --with-gmp=/home/toolsbuild/jenkins-knuth/workspace/avr8-gnu-toolchain/avr8-gnu-toolchain-linux_x86_64 --with-mpc=/home/toolsbuild/jenkins-knuth/workspace/avr8-gnu-toolchain/avr8-gnu-toolchain-linux_x86_64 --enable-fixed-point --with-pkgversion=AVR_8_bit_GNU_Toolchain_3.4.3_1072 --with-bugurl=http://www.atmel.com Thread model: single gcc version 4.8.1 (AVR_8_bit_GNU_Toolchain_3.4.3_1072) Other than that (and a bit pickier with aggregate initializers that don't include all the elements), it builds functional firmware properly. So I guess I would like you guys to confirm that this is a bug or regression, and let me know the bug reference if any. Greetings David Fernandez
Re: Re: Why not implementation of interrupt attribute on IA32/x86-64
Hi, This is slightly off-topic, but there seems to be lots of different interrupt attributes in gcc, one for each different processor, which, in many instances, seem almost the same with different names. also, gcc could decide on the attribute behaviour depending on the target it compiles for. I wonder if there are plans to revise and clean them, or, as there might be code already using them that should not be broken, define some unified ones that make more sense. Just mentioning, as I've programmed for several hardware platforms and is the kind of thing that looks really ugly in gcc. Greetings David F. On 13/03/15 14:08, Andi Kleen wrote: Didier Garcin writes: many OS hobbyist developpers would be pleased GCC implements the interrupt or interrupt_handler attribute for Intel architecture. Would it be so difficult to implement for this architecture ? There are lots of different ways to implement interrupts on x86 (e.g. what state to save, what registers to set up). It would be unlikely that gcc would select a subset that worked for most people. You're better off with a assembler wrapper that does exactly the setup you want. -Andi
Error making a cross-compiler
Hi there, I don't know if this is the right place for questions about the gcc build/install process. Let me know the right place otherwise. I'm trying to compile a cross-compiler from gcc-4.0.2 sources. It is configured this way: /usr/src/redhat/BUILD/gcc-4.0.2/configure --prefix=/usr/local/gcc-msdos --with-local-prefix=/usr/local/gcc-msdos --enable-checking=release --disable-threads --disable-libunwind-exceptions --enable-target-optspace --with-system-zlib --enable-__cxa_atexit --enable-languages=c,c++ --host=i386-redhat-linux --target=i686-pc-msdosdjgpp But at a point during the make process I've got this: make ... make[2]: Entering directory `/root/gcc-build/i686-pc-msdosdjgpp/gcc' for d in libgcc; do \ if [ -d $d ]; then true; else /bin/sh /usr/src/redhat/BUILD/gcc-4.0.2/gcc/../mkinstalldirs $d; fi; \ done mkdir -p -- libgcc if [ -f stmp-dirs ]; then true; else touch stmp-dirs; fi /root/gcc-build/i686-pc-msdosdjgpp/gcc/xgcc -B/root/gcc-build/i686-pc-msdosdjgpp/gcc/ -B/usr/local/gcc-msdos/i686-pc-msdosdjgpp/bin/ -B/usr/local/gcc-msdos/i686-pc-msdosdjgpp/lib/ -isystem /usr/local/gcc-msdos/i686-pc-msdosdjgpp/include -isystem /usr/local/gcc-msdos/i686-pc-msdosdjgpp/sys-include -O2 -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I. -I/usr/src/redhat/BUILD/gcc-4.0.2/gcc -I/usr/src/redhat/BUILD/gcc-4.0.2/gcc/. -I/usr/src/redhat/BUILD/gcc-4.0.2/gcc/../include -I/usr/src/redhat/BUILD/gcc-4.0.2/gcc/../libcpp/include -DL_muldi3 -c /usr/src/redhat/BUILD/gcc-4.0.2/gcc/libgcc2.c -o libgcc/./_muldi3.o cc1: error: ../include/sys/version.h: No such file or directory make[2]: *** [libgcc/./_muldi3.o] Error 1 make[2]: Leaving directory `/root/gcc-build/i686-pc-msdosdjgpp/gcc' make[1]: *** [libgcc.a] Error 2 make[1]: Leaving directory `/root/gcc-build/i686-pc-msdosdjgpp/gcc' make: *** [all-gcc] Error 2 As far as I can see, both isystem directories don't exist in my system. What I'm doing wrong?. Where should I get the missing header files?. Thank you in advance. David.
i686 architecture behaviour in gcc
Hi there,
Nobody seems to know about this in gcc-help, so, there I go:
Forwarded Message
From: David Fernandez <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: i686 architecture behaviour in gcc
Date: Tue, 21 Feb 2006 17:08:32 +
Hi there,
Can anyone explain why has been chosen that -march=i686 makes the
compiler change the normal behaviour, and zero-expand unsigned short
parameters into 32-bit registers by all means?
E.g.
void __attribute(( regparm(2) )) myoutl( d, p )
{
asm("outl%0,(%w1)\n"
:
: "a" (d), "d" (p) );
}
assembled with
gcc -Os -fomit-frame-pointer -march=i586 ...
gives us
outl%eax,(%dx)
ret
but changing "-march=i686" gives us
movzwl %dx,%edx
outl%eax,(%dx)
ret
Is it a bug, or had any developer a good reason to do so?
David
