From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24188 invoked by alias); 30 Aug 2007 19:34:21 -0000 Received: (qmail 24087 invoked by uid 22791); 30 Aug 2007 19:34:20 -0000 X-Spam-Check-By: sourceware.org Received: from secure.latencyzero.com (HELO mail.latencyzero.com) (64.71.153.217) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 30 Aug 2007 19:34:09 +0000 Received: (qmail 31631 invoked from network); 30 Aug 2007 19:34:07 -0000 Received: from unknown (HELO ?10.1.2.251?) (rmann@63.64.55.212) by 0 with ESMTPA; 30 Aug 2007 19:34:07 -0000 In-Reply-To: <20070830192139.GA17633@caradoc.them.org> References: <46D62221.CD184D7@dessent.net> <31BB4D0F-872D-46CC-9230-79AD9B4F6B87@latencyzero.com> <20070830192139.GA17633@caradoc.them.org> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <05AE684A-7CDD-416A-A5A0-855C233A09FF@latencyzero.com> Cc: binutils Content-Transfer-Encoding: 7bit From: Rick Mann Subject: Re: Help with -march and -mcpu issues Date: Thu, 30 Aug 2007 19:51:00 -0000 To: Daniel Jacobowitz X-Mailer: Apple Mail (2.752.3) X-IsSubscribed: yes Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org X-SW-Source: 2007-08/txt/msg00468.txt.bz2 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 = .; } }