The GCC ARM/embedded-4_9-branch is available now
Hi There, To facilitate the development for ARM embedded processors, I just created the GCC embedded-4_9-branch. The branch is described at http://gcc.gnu.org/svn.html. The branch can be viewed at http://gcc.gnu.org/viewcvs/gcc/branches/ARM/embedded-4_9-branch/. You are welcome to submit patch to this branch. BR, Terry
RE: arm/thumb broken on head
> -Original Message- > From: Richard Earnshaw > Sent: Tuesday, November 11, 2014 1:08 AM > To: Joel Sherrill; GCC Mailing List > Cc: Terry Guo > Subject: Re: arm/thumb broken on head > > On 10/11/14 15:26, Joel Sherrill wrote: > > Hi > > > > With gcc, newlib, and binutils head, arm-rtems and arm-eabi both die > > building libgcc2.c for the Thumb. I don't know if this is a recent gcc > > change or binutils having added some new error checking. Anyone got > > any ideas? > > > > /users/joel/test-gcc/b-arm-eabi-gcc/./gcc/xgcc > > -B/users/joel/test-gcc/b-arm-eabi-gcc/./gcc/ -nostdinc > > -B/users/joel/test-gcc/b-arm-eabi-gcc/arm-eabi/newlib/ -isystem > > /users/joel/test-gcc/b-arm-eabi-gcc/arm-eabi/newlib/targ-include > > -isystem /users/joel/test-gcc/gcc/newlib/libc/include > > -B/users/joel/test-gcc/b-arm-eabi-gcc/arm-eabi/libgloss/arm > > -L/users/joel/test-gcc/b-arm-eabi-gcc/arm-eabi/libgloss/libnosys > > -L/users/joel/test-gcc/gcc/libgloss/arm > > -B/users/joel/test-gcc/install-head/arm-eabi/bin/ > > -B/users/joel/test-gcc/install-head/arm-eabi/lib/ -isystem > > /users/joel/test-gcc/install-head/arm-eabi/include -isystem > > /users/joel/test-gcc/install-head/arm-eabi/sys-include-g -O2 -mthumb > > -O2 -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall > > -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes > > -Wmissing-prototypes -Wold-style-definition -isystem ./include > > -fno-inline -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector > > -Dinhibit_libc -fno-inline -I. -I. -I../../.././gcc > > -I../../../../gcc/libgcc -I../../../../gcc/libgcc/. > > -I../../../../gcc/libgcc/../gcc -I../../../../gcc/libgcc/../include > > -DHAVE_CC_TLS -o _muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep > > -DL_muldi3 -c ../../../../gcc/libgcc/libgcc2.c -fvisibility=hidden > > -DHIDE_EXPORTS > > /tmp/cc9EfnXy.s: Assembler messages: > > /tmp/cc9EfnXy.s:69: Error: MOV Rd, Rs with two low registers is not > > permitted on this architecture -- `mov r6,r7' > > > > This is most likely fallout from the migration of thumb1 assembly to unified > syntax. Terry, if this hasn't already been sorted can you take a look? > > R. Sorry for troubles. Indeed this is caused my recent Thumb-1 UAL patch. Some 'mov' instructions require special treatment. I am working on a patch. BR, Terry
RE: arm/thumb broken on head
> -Original Message- > From: Terry Guo > Sent: Tuesday, November 11, 2014 9:08 AM > To: Richard Earnshaw; Joel Sherrill > Cc: GCC Mailing List > Subject: RE: arm/thumb broken on head > > > > > -Original Message- > > From: Richard Earnshaw > > Sent: Tuesday, November 11, 2014 1:08 AM > > To: Joel Sherrill; GCC Mailing List > > Cc: Terry Guo > > Subject: Re: arm/thumb broken on head > > > > On 10/11/14 15:26, Joel Sherrill wrote: > > > Hi > > > > > > With gcc, newlib, and binutils head, arm-rtems and arm-eabi both die > > > building libgcc2.c for the Thumb. I don't know if this is a recent > > > gcc change or binutils having added some new error checking. Anyone > > > got any ideas? > > > > > > /users/joel/test-gcc/b-arm-eabi-gcc/./gcc/xgcc > > > -B/users/joel/test-gcc/b-arm-eabi-gcc/./gcc/ -nostdinc > > > -B/users/joel/test-gcc/b-arm-eabi-gcc/arm-eabi/newlib/ -isystem > > > /users/joel/test-gcc/b-arm-eabi-gcc/arm-eabi/newlib/targ-include > > > -isystem /users/joel/test-gcc/gcc/newlib/libc/include > > > -B/users/joel/test-gcc/b-arm-eabi-gcc/arm-eabi/libgloss/arm > > > -L/users/joel/test-gcc/b-arm-eabi-gcc/arm-eabi/libgloss/libnosys > > > -L/users/joel/test-gcc/gcc/libgloss/arm > > > -B/users/joel/test-gcc/install-head/arm-eabi/bin/ > > > -B/users/joel/test-gcc/install-head/arm-eabi/lib/ -isystem > > > /users/joel/test-gcc/install-head/arm-eabi/include -isystem > > > /users/joel/test-gcc/install-head/arm-eabi/sys-include-g -O2 -mthumb > > > -O2 -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall > > > -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes > > > -Wmissing-prototypes -Wold-style-definition -isystem ./include > > > -fno-inline -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector > > > -Dinhibit_libc -fno-inline -I. -I. -I../../.././gcc > > > -I../../../../gcc/libgcc -I../../../../gcc/libgcc/. > > > -I../../../../gcc/libgcc/../gcc -I../../../../gcc/libgcc/../include > > > -DHAVE_CC_TLS -o _muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep > > > -DL_muldi3 -c ../../../../gcc/libgcc/libgcc2.c -fvisibility=hidden > > > -DHIDE_EXPORTS > > > /tmp/cc9EfnXy.s: Assembler messages: > > > /tmp/cc9EfnXy.s:69: Error: MOV Rd, Rs with two low registers is not > > > permitted on this architecture -- `mov r6,r7' > > > > > > > This is most likely fallout from the migration of thumb1 assembly to > > unified syntax. Terry, if this hasn't already been sorted can you take a look? > > > > R. > > Sorry for troubles. Indeed this is caused my recent Thumb-1 UAL patch. > Some 'mov' instructions require special treatment. I am working on a patch. > > BR, > Terry Fix is committed to trunk at https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=217341. BR, Terry
I cannot disable GCC TLS support thoroughly.
Hello,
I configured my gcc with "--disable-tls" for arm-none-eabi. But it can
still successfully compile the below case:
__thread int i;
int f (void) { return i; }
void main (int j) { i = j; }
The "dg-require-effective-target tls" use this case to check whether
target supports tls. So how to configure GCC to let it fail to compile
this case, and then let the dg test framework thinks the tls is
unsupported? Thanks in advance.
BR,
Terry
Which Binutils should I use for performing daily regression test on trunk?
Hi, I plan to set up daily regression test on trunk for target ARM-NONE-EABI and post results to gcc-testresults mailing list. Which Binutils should I use, the Binutils trunk or the latest released Binutils? And which way is recommended, building from a combined tree or building separately? If there is something I should pay attention to, please let me know. Thanks very much. BR, Terry
Re: ARM Multilibs with --with-mode=thumb
On Wed, May 8, 2013 at 6:14 PM, gnubie gnubie wrote:
> Hi,
> I've noticed odd behaviour when building an ARM compiler with GCC 4.7,
> --with-mode=thumb and multilibs enabled.
>
> If I do a standard c/c++ newlib build with the following multilib options:
> MULTILIB_OPTIONS += marm mthumb
> MULTILIB_DIRNAMES+= arm thumb
>
Watch out the difference between "+=" and "=" when hack the Multilib.
When you configure the gcc with --with-mode=thumb, the default mode is
changed to thumb, thus you need to change the "marm" to "mthumb" in
MULTILIB_DEFAULTS.
Here is a small patch that can help you to implement this:
diff --git a/gcc/config/arm/elf.h b/gcc/config/arm/elf.h
index e0a0aa0..d5f2234 100644
--- a/gcc/config/arm/elf.h
+++ b/gcc/config/arm/elf.h
@@ -113,7 +113,7 @@
#ifndef MULTILIB_DEFAULTS
#define MULTILIB_DEFAULTS \
- { "marm", "mlittle-endian", "mfloat-abi=soft",
"mno-thumb-interwork", "fno-leading-underscore" }
+ { "mthumb", "mlittle-endian", "mfloat-abi=soft",
"mno-thumb-interwork", "fno-leading-underscore" }
#endif
^L
#define TARGET_ASM_FILE_START_APP_OFF true
diff --git a/gcc/config/arm/t-arm-elf b/gcc/config/arm/t-arm-elf
index 25b7acb..e7dda60 100644
--- a/gcc/config/arm/t-arm-elf
+++ b/gcc/config/arm/t-arm-elf
@@ -17,7 +17,7 @@
# along with GCC; see the file COPYING3. If not see
#
RE: How to specify multiple OSDIRNAME suffixes for multilib (Multilib usage with MPX)?
> -Original Message- > From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of > Ilya Enkovich > Sent: Friday, August 09, 2013 8:37 PM > To: GCC Development > Subject: How to specify multiple OSDIRNAME suffixes for multilib (Multilib > usage with MPX)? > > Hi, > > I'm currently trying to create multilib libraries compiled with MPX. > The main difference with existing multilib variants on i386 target is > that new targets (32/mpx, 64/mpx) are compatible with old variants > (32, 64). Also we should not prevent user from using mpx if he does > not have MPX variants for some libraries - legacy versions should be > used instead. Thus we need to check several suffixes instead of one. > E.g. for 64bit MPX binary we should firstly check ../lib64/mpx, then > check ../lib64 and finally the default one. > > I looked at MULTILIB_REUSE and thought it might solve my problem > according to documentation: "And for some targets it is better to > reuse an existing multilib than to fall back to default multilib when > there is no corresponding multilib." [1]. So I tried following > declarations: > > MULTILIB_OSDIRNAMES+= m64/fmpx=../lib64/mpx > MULTILIB_REUSE = m64=m64/fmpx > > But it appeared that only the first entry for some options set counts > when multilibs are parsed in gcc.c and my reuse here is just ignored. > > Is it a wrong implementation of MULTILIB_REUSE or my wrong > understanding of this option? Is there a way to implement mpx > multilibs still allowing legacy ones when some mpx libs are missing? > > [1] http://gcc.gnu.org/onlinedocs/gccint/Target-Fragment.html#Target- > Fragment > > Thanks, > Ilya Hi Ilya, Sorry for the later response. I am the author of MULTILIB_REUSE. So far this feature is not flexible enough to meet your requirement. It can't dynamically decide to choose m64/fmpx if such libraries are there, then secondly choose m64 if m64/fmpx don't exist. This feature only makes a static decision. The following statement: MULTILIB_REUSE = m64=m64/fmpx means that when options m64 and fmpx are given, we should reuse libraries for m64 always. And for this purpose, we also need: MULTILIB_EXCEPTIONS = m64/fmpx to make sure libraries for "m64 fmpx" won't be built. If m64/fmpx isn't excluded, the MULTILIB_REUSE will think the required libraries are there and no need to reuse. IMHO, the way used by gcc to select multilib is based on string match rather than detecting the existence of libraries. So the flexible way like you wanted isn't supported yet. BR, Terry
RE: How to specify multiple OSDIRNAME suffixes for multilib (Multilib usage with MPX)?
> -Original Message- > From: Ilya Enkovich [mailto:enkovich@gmail.com] > Sent: Monday, August 12, 2013 4:37 PM > To: Terry Guo > Cc: GCC Development > Subject: Re: How to specify multiple OSDIRNAME suffixes for multilib > (Multilib usage with MPX)? > > Hi Terry, > > Thanks a lot for your reply! I suppose I have to introduce some new option > like MULTILIB_COMPATIBLE to produce additional search locations for > libraries. Does it sound reasonable? Any advice on implementation? > > Thanks, > Ilya > Make sense to me. And I think the feature you mentioned can cover MULTILIB_REUSE, so to keep things simple, I would prefer to unifying them into one term, either MULTILIB_COMPATIBLE or MULTILIB_REUSE. I am ok with both names. In terms of implementation, I think gcc as a driver program only decides the path to libraries based on command line options and multilib configuration, the linker will finally search the libraries and link them together. When MULTILIB_COMPATIBLE is provided, gcc can select more than one paths and pass them to linker. When there is only one compatible library, the linker can find it by searching all paths, the whole thing can work. But when there are more than one compatible libraries spread in different paths, I am not sure it works. You can try it out. BR, Terry > 2013/8/12 Terry Guo : > > > > > >> -Original Message- > >> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf > >> Of Ilya Enkovich > >> Sent: Friday, August 09, 2013 8:37 PM > >> To: GCC Development > >> Subject: How to specify multiple OSDIRNAME suffixes for multilib > >> (Multilib usage with MPX)? > >> > >> Hi, > >> > >> I'm currently trying to create multilib libraries compiled with MPX. > >> The main difference with existing multilib variants on i386 target is > >> that new targets (32/mpx, 64/mpx) are compatible with old variants > >> (32, 64). Also we should not prevent user from using mpx if he does > >> not have MPX variants for some libraries - legacy versions should be > >> used instead. Thus we need to check several suffixes instead of one. > >> E.g. for 64bit MPX binary we should firstly check ../lib64/mpx, then > >> check ../lib64 and finally the default one. > >> > >> I looked at MULTILIB_REUSE and thought it might solve my problem > >> according to documentation: "And for some targets it is better to > >> reuse an existing multilib than to fall back to default multilib when > >> there is no corresponding multilib." [1]. So I tried following > >> declarations: > >> > >> MULTILIB_OSDIRNAMES+= m64/fmpx=../lib64/mpx MULTILIB_REUSE = > >> m64=m64/fmpx > >> > >> But it appeared that only the first entry for some options set counts > >> when multilibs are parsed in gcc.c and my reuse here is just ignored. > >> > >> Is it a wrong implementation of MULTILIB_REUSE or my wrong > >> understanding of this option? Is there a way to implement mpx > >> multilibs still allowing legacy ones when some mpx libs are missing? > >> > >> [1] http://gcc.gnu.org/onlinedocs/gccint/Target-Fragment.html#Target- > >> Fragment > >> > >> Thanks, > >> Ilya > > > > Hi Ilya, > > > > Sorry for the later response. I am the author of MULTILIB_REUSE. So > > far this feature is not flexible enough to meet your requirement. It > > can't dynamically decide to choose m64/fmpx if such libraries are > > there, then secondly choose m64 if m64/fmpx don't exist. This feature > > only makes a static decision. The following statement: > > MULTILIB_REUSE = m64=m64/fmpx > > means that when options m64 and fmpx are given, we should reuse > > libraries for m64 always. And for this purpose, we also need: > > MULTILIB_EXCEPTIONS = m64/fmpx to make sure libraries for "m64 fmpx" > > won't be built. > > > > If m64/fmpx isn't excluded, the MULTILIB_REUSE will think the required > > libraries are there and no need to reuse. > > > > IMHO, the way used by gcc to select multilib is based on string match > > rather than detecting the existence of libraries. So the flexible way > > like you wanted isn't supported yet. > > > > BR, > > Terry > > > > > > > >
RE: Strange behavior of libstdc++ regression test
> > "Terry Guo" writes: > > > make[1]: *** [check-recursive] Error 1 > > make[1]: Target `check' not remade because of errors. > > make[1]: Leaving directory > > `/home/build/gcc-4-7-daily-test/build-linux/gcc-final/arm-none- > eabi/libstdc+ > > +-v3' > > make: *** [check-target-libstdc++-v3] Error 2 > > make: Target `check-target' not remade because of errors. > > You had unexpected failures/successes. Look at the first error, not > the > last one. > Ah, you are right. I just thought the "make -k" should keep going and omit all the errors. Now I think I should use "make -k -i" to do it. Thanks for the help. BR, Terry
Why not remove entry for stripped function in ELF .debug_info section
Hi,
I have following code which will be built with options
"-ffunction-sections -fdata-sections -Wl,--gc-sections
-Wl,-Map=test.map":
#include
static int unusedint=5;
static int usedint=1;
int unused(void) {
return 1;
}
int foo(void) {
return usedint;
}
int main(void) {
if (foo())
exit(0);
else
abort();
}
According to the generated map file, the function named "unused" is
discarded in final .out file.
Discarded input sections
.text.unused 0x 0x10 gcsec-1.o
But when check .debug_info section of .out file, I can still see entry
for this deadstripped function:
<0>: Abbrev Number: 1 (DW_TAG_compile_unit)
< c> DW_AT_producer: (indirect string, offset: 0xe): GNU C
4.8.0 20120612 (experimental) -fpreprocessed -mthumb -mcpu=cortex-m3
-g2 -ffunction-sections -fdata-sections -fno-inline
<1><79>: Abbrev Number: 4 (DW_TAG_subprogram)
<7a> DW_AT_external: 1
<7a> DW_AT_name: (indirect string, offset: 0x8d): unused
<7e> DW_AT_decl_file : 1
<7f> DW_AT_decl_line : 16
<80> DW_AT_prototyped : 1
<80> DW_AT_type: <0x48>
<84> DW_AT_low_pc : 0x0
<88> DW_AT_high_pc : 0x0
<8c> DW_AT_frame_base : 1 byte block: 9c (DW_OP_call_frame_cfa)
<8e> Unknown AT value: 2117: 1
Is this expected behavior? Why not remove this entry? Thanks in
advance for any help.
BR,
Terry
