Re: Help with -march and -mcpu issues

Re: Help with -march and -mcpu issues

[Rick Mann]

On Aug 29, 2007, at 6:49 PM, Brian Dessent wrote:

> Rick Mann wrote:
>
>> $ arm-elf-gcc -c main.c -o main.o
>> $ arm-elf-ld  -e _start -o h.elf --script=link.lds start.o main.o
>> $ arm-elf-objcopy --output-target=binary --gap-fill=0xff h.elf h
>>
>> The resulting file "h" works very well.
>>
>> However, if I add -mcpu=xscale or -march=armv5te to the gcc line, I
>> get errors like this:
>>
>> arm-elf-ld: ERROR: main.o uses VFP instructions, whereas h.elf  
>> does not
>
> You should ask this on the binutils list.  The linker is not  
> provided by
> nor part of gcc, and your question seems to be about the linker.

You're absolutely right, binutils seems to be more appropriate.

> Where does start.o come from?  Are you not also rebuilding it with the
> given -march?  I'm guessing that the reason you get the error is that
> the linker sees two objects that were built with different -march
> settings (or rather one with the default and another with something
> else), and that's why it's complaining.  But that's just  
> speculation, I
> don't actually know.

Sorry, I meant to sanitize that out. I have a simple file start.S  
which provides a bit of glue and BSS clearing before calling main.  
It's also built with the same -march setting.

The thing that bugs me, again, is that it's complaining about  
differences between the .o files and the thing it's linking the .o  
files into, which is made up only of those .o files!

$ arm-elf-gcc -march=armv5te -ffreestanding -nostdlib -std=c99 - 
Xlinker -e -Xlinker _start -Xlinker --script=link.lds -o h.elf  
start.o main.o -lgcc -lc -lm
/usr/local/arm-4.2.0/lib/gcc/arm-elf/4.2.0/../../../../arm-elf/bin/ 
ld: ERROR: obj/main.o uses VFP instructions, whereas h.elf does not
/usr/local/arm-4.2.0/lib/gcc/arm-elf/4.2.0/../../../../arm-elf/bin/ 
ld: failed to merge target specific data of file obj/main.o


Interestingly, it doesn't seem to complain about start.o.

-- 
Rick

Re: Help with -march and -mcpu issues

[Daniel Jacobowitz]

On Thu, Aug 30, 2007 at 12:12:20PM -0700, Rick Mann wrote:
> The thing that bugs me, again, is that it's complaining about differences 
> between the .o files and the thing it's linking the .o files into, which is 
> made up only of those .o files!

No it isn't:

> $ arm-elf-gcc -march=armv5te -ffreestanding -nostdlib -std=c99 -Xlinker -e 
> -Xlinker _start -Xlinker --script=link.lds -o h.elf start.o main.o -lgcc -lc 
> -lm

You've got libraries in there too plus any startfiles that the
compiler or your link.lds add.  Take a look at the
-Wl,-Map,mapfile.txt output file to see what else is being linked in.
You can use readelf -h to see the elf flags word for each object;
the linker error is complaining about EF_ARM_VFP_FLOAT.  One of your
objects was compiled with a toolchain that expects FPA emulation.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Help with -march and -mcpu issues

[Rick Mann]

On Aug 30, 2007, at 12:21 PM, Daniel Jacobowitz wrote:

> You've got libraries in there too plus any startfiles that the
> compiler or your link.lds add.  Take a look at the
> -Wl,-Map,mapfile.txt output file to see what else is being linked in.
> You can use readelf -h to see the elf flags word for each object;
> the linker error is complaining about EF_ARM_VFP_FLOAT.  One of your
> objects was compiled with a toolchain that expects FPA emulation.

You're right, in that invocation, I do. Unfortunately, I left that in  
when I was doing some other experimentation. I took those libraries  
out, and adding the mapfile option to the link CC invocation, I get  
the following (there are actually a couple other files in there, all  
compiled the same way). I'm not sure where to look for EF_ARM_VFP_FLOAT.

I took a look in the linker script, and found something that might've  
been causing the problem: OUTPUT_ARCH(arm) But, I changed that to  
OUTPUT_ARCH(armv5te) and it didn't change anything. I've include the  
linker script at the bottom. I'll keep experimenting.

Forgive me for not understanding ld very well; I'm catching up as  
fast as I can!

TIA,

-- 
Rick

----------------------------- mapfile.txt:

Allocating common symbols
Common symbol       size              file

gFrameBuffer1       0x96000           obj/main.o

Memory Configuration

Name             Origin             Length             Attributes
*default*        0x00000000         0xffffffff

Linker script and memory map

                 0x80008000                . = 0x80008000
                 0x80008000                . = ALIGN (0x4)

.text           0x80008000     0x1594
  *(.text)
  .text          0x80008000       0x68 obj/start.o
                 0x80008000                _start
                 0x80008058                data_start
  .text          0x80008068      0x228 obj/Util.o
                 0x8000824c                writeHex
                 0x80008120                hexToAscii
                 0x800080b4                writeString
                 0x80008068                mhn_serial_write
  .text          0x80008290      0x960 obj/lcd.o
                 0x80008920                setLCCR1
                 0x80008a18                setLCCR3
                 0x80008290                initLCD
                 0x800085bc                disableLCD
                 0x800085e0                setLCCR0
                 0x80008598                enableLCD
                 0x8000899c                setLCCR2
  .text          0x80008bf0      0x9a4 obj/main.o
                 0x800094b4                eraseFrameBuffer
                 0x80008bf0                main
                 0x80009350                fillRect

.glue_7         0x80009594        0x0
  .glue_7        0x80009594        0x0 obj/start.o
  .glue_7        0x80009594        0x0 obj/Util.o
  .glue_7        0x80009594        0x0 obj/lcd.o
  .glue_7        0x80009594        0x0 obj/main.o

.glue_7t        0x80009594        0x0
  .glue_7t       0x80009594        0x0 obj/start.o
  .glue_7t       0x80009594        0x0 obj/Util.o
  .glue_7t       0x80009594        0x0 obj/lcd.o
  .glue_7t       0x80009594        0x0 obj/main.o
                 0x80009594                . = ALIGN (0x4)

.rodata         0x80009594       0xf8
  *(.rodata)
  .rodata        0x80009594        0x4 obj/Util.o
  .rodata        0x80009598       0xf4 obj/main.o
                 0x8000968c                . = ALIGN (0x4)

.data           0x8000968c       0x10
                 0x8000968c                __data_start_foo = .
  *(.data)
  .data          0x8000968c        0x0 obj/start.o
  .data          0x8000968c       0x10 obj/Util.o
  .data          0x8000969c        0x0 obj/lcd.o
  .data          0x8000969c        0x0 obj/main.o
                 0x8000969c                . = ALIGN (0x4)

.got
  *(.got)
                 0x8000969c                . = ALIGN (0x4)

.commandlist    0x8000969c        0x0
                 0x8000969c                __commandlist_start = .
  *(.commandlist)
                 0x8000969c                __commandlist_end = .
                 0x8000969c                . = ALIGN (0x4)

.initlist       0x8000969c        0x0
                 0x8000969c                __initlist_start = .
  *(.initlist)
                 0x8000969c                __initlist_end = .
                 0x8000969c                . = ALIGN (0x4)

.exitlist       0x8000969c        0x0
                 0x8000969c                __exitlist_start = .
  *(.exitlist)
                 0x8000969c                __exitlist_end = .
                 0x8000969c                . = ALIGN (0x4)

.bss            0x8000969c    0x98000
                 0x8000969c                __bss_start = .
  *(.bss)
  .bss           0x8000969c        0x0 obj/start.o
  .bss           0x8000969c        0x0 obj/Util.o
  .bss           0x8000969c        0x0 obj/lcd.o
  .bss           0x8000969c        0x0 obj/main.o
  *(COMMON)
  COMMON         0x8000969c    0x96000 obj/main.o
                 0x8000969c                gFrameBuffer1
                 0x8009f69c                . = ALIGN (0x4)
                 0x800a169c                . = (. + 0x2000)
  *fill*         0x8009f69c     0x2000 00
                 0x800a169c                __stack_end = .
                 0x800a169c                __bss_end = .
LOAD obj/start.o
LOAD obj/Util.o
LOAD obj/lcd.o
LOAD obj/main.o
OUTPUT(h.elf elf32-littlearm)

.comment        0x00000000       0x6a
  .comment       0x00000000       0x34 obj/start.o
  .comment       0x00000034       0x12 obj/Util.o
  .comment       0x00000046       0x12 obj/lcd.o
  .comment       0x00000058       0x12 obj/main.o

----------------------------- link.lds:

OUTPUT_FORMAT("elf32-littlearm", "elf32-littlearm", "elf32-littlearm")
OUTPUT_ARCH(arm)
ENTRY(_start)
SECTIONS
{
	. = 0x80008000;

	. = ALIGN(4);
	.text : { *(.text) }

	. = ALIGN(4);
	.rodata : { *(.rodata) }

	. = ALIGN(4);
	.data : {
		__data_start_foo = .;
		*(.data)
	}

	. = ALIGN(4);
	.got : { *(.got) }

	. = ALIGN(4);
	.commandlist : {
		__commandlist_start = .;
		*(.commandlist)
		__commandlist_end = .;
	}

	. = ALIGN(4);
	.initlist : {
		__initlist_start = .;
		*(.initlist)
		__initlist_end = .;
	}

	. = ALIGN(4);
	.exitlist : {
		__exitlist_start = .;
		*(.exitlist)
		__exitlist_end = .;
	}

	/* the BSS section should be the last section */
	. = ALIGN(4);
	.bss : {
		__bss_start = .;
		/* first the real BSS data */
		*(.bss)
		*(COMMON)

		/* and next the stack */
		. = ALIGN(4);

		/* allocate an 8kB stack */		
		. = . + 8 * 1024;

		__stack_end = .;
		__bss_end = .;
	}
}

Re: Help with -march and -mcpu issues

[Daniel Jacobowitz]

On Thu, Aug 30, 2007 at 12:34:00PM -0700, Rick Mann wrote:
> You're right, in that invocation, I do. Unfortunately, I left that in when I 
> was doing some other experimentation. I took those libraries out, and adding 
> the mapfile option to the link CC invocation, I get the following (there are 
> actually a couple other files in there, all compiled the same way). I'm not 
> sure where to look for EF_ARM_VFP_FLOAT.

LOAD obj/start.o
LOAD obj/Util.o
LOAD obj/lcd.o
LOAD obj/main.o

That means those objects are basically on your command line.

-- 
Daniel Jacobowitz
CodeSourcery

SOLVED: Help with -march and -mcpu issues

[Rick Mann]

I was starting to respond to your email, when all of a sudden it's  
building. I can now do this, with both -mcpu and -march set, and it  
works:

arm-elf-gcc -Wl,-Map,mapfile.txt -mcpu=xscale -march=armv5te - 
ffreestanding -nostdlib -std=c99 -Xlinker -e -Xlinker _start -Xlinker  
--script=link.lds -o h.elf obj/start.o obj/Util.o obj/lcd.o obj/ 
main.o -lgcc -lc -lm


Now this works. I don't know what else I changed. Hmm. Maybe it's  
because I left the arch flags off of the start.S build invocation. I  
was so thrown by the wording of the error message, that I didn't  
realize it meant one or more input files didn't match. Thank you for  
the help!

-- 
Rick




-------------




On Aug 30, 2007, at 12:38 PM, Daniel Jacobowitz wrote:

> LOAD obj/start.o
> LOAD obj/Util.o
> LOAD obj/lcd.o
> LOAD obj/main.o
>
> That means those objects are basically on your command line.

So, using readelf -h, I see that all four files have

   Flags:                             0x600, GNU EABI, software FP, VFP

Is that what I should be looking at? I see the VFP in there.


$ arm-elf-readelf -h obj/*.o

File: obj/Util.o
ELF Header:
   Magic:   7f 45 4c 46 01 01 01 61 00 00 00 00 00 00 00 00
   Class:                             ELF32
   Data:                              2's complement, little endian
   Version:                           1 (current)
   OS/ABI:                            ARM
   ABI Version:                       0
   Type:                              REL (Relocatable file)
   Machine:                           ARM
   Version:                           0x1
   Entry point address:               0x0
   Start of program headers:          0 (bytes into file)
   Start of section headers:          708 (bytes into file)
   Flags:                             0x600, GNU EABI, software FP, VFP
   Size of this header:               52 (bytes)
   Size of program headers:           0 (bytes)
   Number of program headers:         0
   Size of section headers:           40 (bytes)
   Number of section headers:         10
   Section header string table index: 7

File: obj/lcd.o
ELF Header:
   Magic:   7f 45 4c 46 01 01 01 61 00 00 00 00 00 00 00 00
   Class:                             ELF32
   Data:                              2's complement, little endian
   Version:                           1 (current)
   OS/ABI:                            ARM
   ABI Version:                       0
   Type:                              REL (Relocatable file)
   Machine:                           ARM
   Version:                           0x1
   Entry point address:               0x0
   Start of program headers:          0 (bytes into file)
   Start of section headers:          2528 (bytes into file)
   Flags:                             0x600, GNU EABI, software FP, VFP
   Size of this header:               52 (bytes)
   Size of program headers:           0 (bytes)
   Number of program headers:         0
   Size of section headers:           40 (bytes)
   Number of section headers:         9
   Section header string table index: 6

File: obj/main.o
ELF Header:
   Magic:   7f 45 4c 46 01 01 01 61 00 00 00 00 00 00 00 00
   Class:                             ELF32
   Data:                              2's complement, little endian
   Version:                           1 (current)
   OS/ABI:                            ARM
   ABI Version:                       0
   Type:                              REL (Relocatable file)
   Machine:                           ARM
   Version:                           0x1
   Entry point address:               0x0
   Start of program headers:          0 (bytes into file)
   Start of section headers:          2848 (bytes into file)
   Flags:                             0x600, GNU EABI, software FP, VFP
   Size of this header:               52 (bytes)
   Size of program headers:           0 (bytes)
   Number of program headers:         0
   Size of section headers:           40 (bytes)
   Number of section headers:         10
   Section header string table index: 7

File: obj/start.o
ELF Header:
   Magic:   7f 45 4c 46 01 01 01 61 00 00 00 00 00 00 00 00
   Class:                             ELF32
   Data:                              2's complement, little endian
   Version:                           1 (current)
   OS/ABI:                            ARM
   ABI Version:                       0
   Type:                              REL (Relocatable file)
   Machine:                           ARM
   Version:                           0x1
   Entry point address:               0x0
   Start of program headers:          0 (bytes into file)
   Start of section headers:          268 (bytes into file)
   Flags:                             0x600, GNU EABI, software FP, VFP
   Size of this header:               52 (bytes)
   Size of program headers:           0 (bytes)
   Number of program headers:         0
   Size of section headers:           40 (bytes)
   Number of section headers:         9
   Section header string table index: 6

Re: Help with -march and -mcpu issues

[Paul Brook]

> > The thing that bugs me, again, is that it's complaining about differences
> > between the .o files and the thing it's linking the .o files into, which
> > is made up only of those .o files!
>
> No it isn't:
> > $ arm-elf-gcc -march=armv5te -ffreestanding -nostdlib -std=c99 -Xlinker
> > -e -Xlinker _start -Xlinker --script=link.lds -o h.elf start.o main.o
> > -lgcc -lc -lm
>
> You've got libraries in there too plus any startfiles that the
> compiler or your link.lds add.  Take a look at the
> -Wl,-Map,mapfile.txt output file to see what else is being linked in.
> You can use readelf -h to see the elf flags word for each object;
> the linker error is complaining about EF_ARM_VFP_FLOAT.  One of your
> objects was compiled with a toolchain that expects FPA emulation.

I'll note that's it's fairly common for older toolchains to be incorrectly 
configured, and produce bogus markings by default.
This should not be a problem on EABI targets where we have proper object 
attributes, and corresponding assembly directives.

Paul

Help with -march and -mcpu issues

[Rick Mann]

Hi. I'm using GCC to target an ARM (XScale) processor. I've  
successfully built code that runs on the target hardware, but I'm  
trying to understand better some of the nuances.

I should point out that I've asked this question on the GNUARM list  
and gotten no responses.

I have a very simple situation. A single main.c and start.S are  
compiled, then linked using ld, then stripped with objcopy and  
finally downloaded to the target. However, if I add -march=armv5te, I  
get a very puzzling error. Here are the basic invocations:

$ arm-elf-gcc -c main.c -o main.o
$ arm-elf-ld  -e _start -o h.elf --script=link.lds start.o main.o
$ arm-elf-objcopy --output-target=binary --gap-fill=0xff h.elf h

The resulting file "h" works very well.

However, if I add -mcpu=xscale or -march=armv5te to the gcc line, I  
get errors like this:

arm-elf-ld: ERROR: main.o uses VFP instructions, whereas h.elf does not

What's puzzling to me about this is that h.elf is what's being built  
by ld. Presumably there's an option to ld to make it recognize the  
architecture, but I'm not sure what it is. I tried to change the  
build steps to call gcc instead of ld, as follows (although I'm not  
at all sure this is the correct approach):

$ arm-elf-gcc -ffreestanding -nostdlib -std=c99 \
	-Xlinker -e -Xlinker _start -Xlinker --script=link.lds \
	-v -o h.elf start.o main.o


Which seems to have produced the exact same final output (after  
objcopy). However, when I added -march=armv5e to the gcc invocations,  
I still get the error about VFP instructions.


I sure hope there's a GCC guru out there who can enlighten me. Thanks!

-- 
Rick