* gas: undefined symbol in immediate operand
@ 2006-08-24 10:05 Jeremy Dexter
2006-08-24 10:43 ` Richard Earnshaw
2006-08-24 10:49 ` Nick Clifton
0 siblings, 2 replies; 6+ messages in thread
From: Jeremy Dexter @ 2006-08-24 10:05 UTC (permalink / raw)
To: binutils
Hi
I'm finding that if I accidentally enter an undefined symbol name as an
*immediate* operand, then as will accept it without any warning. I've tried
this on binutils 2.14 and 2.17 for ARM and PowerPC.
For example, the ARM assembler produces the following:
.equ Moo, 0x42
297 0148 000080E3 orr r0,r0,#moo
Note the typo in the symbol name. The assembler accepts it and adds an
undefined symbol "moo" to the object file, but the linker will not flag it
as undefined, which I presume is because there is no valid reference to it.
So you end up with code that ORs the value 0x00 rather than 0x42.
I would have thought that the assembler is at fault here. An immediate
operand should resolve to a *constant* - an external symbol reference should
not be accepted here. Or am I missing something?
Thanks in advance!
Jeremy
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: gas: undefined symbol in immediate operand 2006-08-24 10:05 gas: undefined symbol in immediate operand Jeremy Dexter @ 2006-08-24 10:43 ` Richard Earnshaw 2006-08-24 10:49 ` Nick Clifton 1 sibling, 0 replies; 6+ messages in thread From: Richard Earnshaw @ 2006-08-24 10:43 UTC (permalink / raw) To: Jeremy Dexter; +Cc: binutils On Thu, 2006-08-24 at 04:51, Jeremy Dexter wrote: > Hi > > I'm finding that if I accidentally enter an undefined symbol name as an > *immediate* operand, then as will accept it without any warning. I've tried > this on binutils 2.14 and 2.17 for ARM and PowerPC. > > For example, the ARM assembler produces the following: > > .equ Moo, 0x42 > 297 0148 000080E3 orr r0,r0,#moo > > Note the typo in the symbol name. The assembler accepts it and adds an > undefined symbol "moo" to the object file, but the linker will not flag it > as undefined, which I presume is because there is no valid reference to it. > So you end up with code that ORs the value 0x00 rather than 0x42. > > I would have thought that the assembler is at fault here. An immediate > operand should resolve to a *constant* - an external symbol reference should > not be accepted here. Or am I missing something? Not quite. On some processors an undefined symbol can be resolved by the assembler to use a relocation (so that some external file can define the value). So the rule in the assembler is If there is no acceptable relocation for the missing symbol generate an error. Otherwise, generate that relocation and the linker must raise the error if the symbol is undefined (or can't fit the value into the space available). R. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: gas: undefined symbol in immediate operand 2006-08-24 10:05 gas: undefined symbol in immediate operand Jeremy Dexter 2006-08-24 10:43 ` Richard Earnshaw @ 2006-08-24 10:49 ` Nick Clifton 2006-08-25 7:44 ` Jeremy Dexter 1 sibling, 1 reply; 6+ messages in thread From: Nick Clifton @ 2006-08-24 10:49 UTC (permalink / raw) To: Jeremy Dexter; +Cc: binutils Hi Jeremy, > I'm finding that if I accidentally enter an undefined symbol name as an > *immediate* operand, then as will accept it without any warning. I've tried > this on binutils 2.14 and 2.17 for ARM and PowerPC. Are you sure about this ? I just tried an arm-eabi toolchain built from the 2.17 sources and using your test case: > .equ Moo, 0x42 > orr r0,r0,#moo I received this error message: jim.s: Assembler messages: jim.s:5: Error: undefined symbol moo used as an immediate value > Note the typo in the symbol name. The assembler accepts it and adds an > undefined symbol "moo" to the object file, but the linker will not flag it > as undefined, which I presume is because there is no valid reference to it. No if the linker does behave this way then it is a bug. Assuming that the assembler does pass the reference to the undefined "moo" symbol on to the linker, then the linker should complain about it. The only reason it would not is if the reference to the symbol is in a section of code that is being discarded and not included in the final executable. Can you put together a full test case to demonstrate the problem, including specifying which toolchain(s) you use ? Cheers Nick ^ permalink raw reply [flat|nested] 6+ messages in thread
* RE: gas: undefined symbol in immediate operand 2006-08-24 10:49 ` Nick Clifton @ 2006-08-25 7:44 ` Jeremy Dexter 2006-08-25 10:51 ` Nick Clifton 0 siblings, 1 reply; 6+ messages in thread From: Jeremy Dexter @ 2006-08-25 7:44 UTC (permalink / raw) To: binutils Thanks for the replies Nick and Richard I'm using a pre-built ARM toolchain (supplied with an embedded development system) running on Windows under cygwin. Using a very simple test case I get: C:\jd\svn\can_trunk>arm-uclibc-as -a test.s -o test.o ARM GAS test.s page 1 1 .equ Moo, 0x42 2 0000 000080E3 orr r0,r0,#moo 3 0004 420080E3 orr r0,r0,#Moo 4 0008 00009FE5 ldr r0, =bruce 5 000c FEFFFFEA b freddy 6 0010 00000000 .end ?ARM GAS test.s page 2 DEFINED SYMBOLS test.s:1 *ABS*:00000042 Moo UNDEFINED SYMBOLS moo bruce freddy C:\jd\svn\can_trunk>arm-uclibc-objdump -xtr test.o test.o: file format elf32-littlearm test.o architecture: arm, flags 0x00000011: HAS_RELOC, HAS_SYMS start address 0x00000000 private flags = 0: [APCS-32] [FPA float format] Sections: Idx Name Size VMA LMA File off Algn 0 .text 00000014 00000000 00000000 00000034 2**2 CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE 1 .data 00000000 00000000 00000000 00000048 2**0 CONTENTS, ALLOC, LOAD, DATA 2 .bss 00000000 00000000 00000000 00000048 2**0 ALLOC SYMBOL TABLE: 00000000 l d .text 00000000 00000000 l d .data 00000000 00000000 l d .bss 00000000 00000042 l *ABS* 00000000 Moo 00000000 *UND* 00000000 moo 00000000 *UND* 00000000 bruce 00000000 *UND* 00000000 freddy RELOCATION RECORDS FOR [.text]: OFFSET TYPE VALUE 0000000c R_ARM_PC24 freddy 00000010 R_ARM_ABS32 bruce ------------------ We've also tried this on a more recent PowerPC toolchain, this time running on Linux and get a similar result: jeff@trantor:~/prj/dt8x/bantha/Src/Bootstrap$ powerpc-eabi-as -a -mregnames tmp.s GAS LISTING tmp.s page 1 1 .equ MOO, 0xff000000 2 3 # .org 0x0100 # reset/NMI vector 4 .global _start 5 _start: 6 7 0000 3FE00000 lis r31,moo@h 8 0004 3FE0FF00 lis r31,MOO@h 9 0008 4E800020 blr 10 11 GAS LISTING tmp.s page 2 DEFINED SYMBOLS tmp.s:1 *ABS*:ff000000 MOO tmp.s:5 .text:00000000 _start UNDEFINED SYMBOLS moo jeff@trantor:~/prj/dt8x/bantha/Src/Bootstrap$ powerpc-eabi-as --version GNU assembler 060810 20060810 Copyright 2005 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. This assembler was configured for a target of `powerpc-eabi'. ---------------- The objdump output shows that the assembler hasn't created a relocation entry for the undefined "moo" symbol, unlike the undefined "bruce" and "freddy" symbols, but it hasn't generated an error either. This does not seem right. It's interesting that you got an error message using the current ARM version, so maybe this has been fixed between 2.14 & 2.17, although I didn't see anything in the release notes. However the PowerPC version we have very recent and also gives no error message. cheers Jeremy. -----Original Message----- From: Nick Clifton Sent: Thursday, 24 August 2006 8:05 pm To: Jeremy Dexter Cc: binutils@sourceware.org Subject: Re: gas: undefined symbol in immediate operand Hi Jeremy, > I'm finding that if I accidentally enter an undefined symbol name as an > *immediate* operand, then as will accept it without any warning. I've tried > this on binutils 2.14 and 2.17 for ARM and PowerPC. Are you sure about this ? I just tried an arm-eabi toolchain built from the 2.17 sources and using your test case: > .equ Moo, 0x42 > orr r0,r0,#moo I received this error message: jim.s: Assembler messages: jim.s:5: Error: undefined symbol moo used as an immediate value > Note the typo in the symbol name. The assembler accepts it and adds an > undefined symbol "moo" to the object file, but the linker will not flag it > as undefined, which I presume is because there is no valid reference to it. No if the linker does behave this way then it is a bug. Assuming that the assembler does pass the reference to the undefined "moo" symbol on to the linker, then the linker should complain about it. The only reason it would not is if the reference to the symbol is in a section of code that is being discarded and not included in the final executable. Can you put together a full test case to demonstrate the problem, including specifying which toolchain(s) you use ? Cheers Nick ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: gas: undefined symbol in immediate operand 2006-08-25 7:44 ` Jeremy Dexter @ 2006-08-25 10:51 ` Nick Clifton 2006-08-28 2:04 ` Jeremy Dexter 0 siblings, 1 reply; 6+ messages in thread From: Nick Clifton @ 2006-08-25 10:51 UTC (permalink / raw) To: Jeremy Dexter; +Cc: binutils Hi Jeremy, > I'm using a pre-built ARM toolchain (supplied with an embedded development > system) running on Windows under cygwin. I think that you must have an old version of the ARM assembler. The current versions definitely do report an error for the use of an undefined symbol as an immediate operand. > We've also tried this on a more recent PowerPC toolchain, this time running > on Linux and get a similar result: > The objdump output shows that the assembler hasn't created a relocation > entry for the undefined "moo" symbol, What objdump output ? When I tried running objdump I saw this: $ objdump -Dr test.o test.o: file format elf32-powerpc Disassembly of section .text: 00000000 <_start>: 0: 3f e0 00 00 lis r31,0 2: R_PPC_ADDR16_HI moo 4: 3f e0 ff 00 lis r31,-256 8: 4e 80 00 20 blr Which clearly does show the reloc against symbol "moo". Furthermore, when I tried to link this object file, I received an error message: $ ld test.o test.o: In function `_start': (.text+0x2): undefined reference to `moo' This is which an assembler and linker compiled from today's binutils sources. Cheers Nick ^ permalink raw reply [flat|nested] 6+ messages in thread
* RE: gas: undefined symbol in immediate operand 2006-08-25 10:51 ` Nick Clifton @ 2006-08-28 2:04 ` Jeremy Dexter 0 siblings, 0 replies; 6+ messages in thread From: Jeremy Dexter @ 2006-08-28 2:04 UTC (permalink / raw) To: binutils Hi Nick OK, I tried this on our PowerPC assembler and it works as you describe, ie. a relocation entry is generated. So basically it looks like the "Error: undefined symbol moo used as an immediate value" message was added to the ARM assembler sometime after 2.14. It's not really practical for me to upgrade to the latest ARM tools so I'll just live with it for now. Thanks again for your assistance! cheers Jeremy -----Original Message----- From: Nick Clifton Sent: Friday, 25 August 2006 5:44 pm To: Jeremy Dexter Cc: binutils@sourceware.org Subject: Re: gas: undefined symbol in immediate operand Hi Jeremy, > I'm using a pre-built ARM toolchain (supplied with an embedded development > system) running on Windows under cygwin. I think that you must have an old version of the ARM assembler. The current versions definitely do report an error for the use of an undefined symbol as an immediate operand. > We've also tried this on a more recent PowerPC toolchain, this time running > on Linux and get a similar result: > The objdump output shows that the assembler hasn't created a relocation > entry for the undefined "moo" symbol, What objdump output ? When I tried running objdump I saw this: $ objdump -Dr test.o test.o: file format elf32-powerpc Disassembly of section .text: 00000000 <_start>: 0: 3f e0 00 00 lis r31,0 2: R_PPC_ADDR16_HI moo 4: 3f e0 ff 00 lis r31,-256 8: 4e 80 00 20 blr Which clearly does show the reloc against symbol "moo". Furthermore, when I tried to link this object file, I received an error message: $ ld test.o test.o: In function `_start': (.text+0x2): undefined reference to `moo' This is which an assembler and linker compiled from today's binutils sources. Cheers Nick ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2006-08-28 1:43 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2006-08-24 10:05 gas: undefined symbol in immediate operand Jeremy Dexter 2006-08-24 10:43 ` Richard Earnshaw 2006-08-24 10:49 ` Nick Clifton 2006-08-25 7:44 ` Jeremy Dexter 2006-08-25 10:51 ` Nick Clifton 2006-08-28 2:04 ` Jeremy Dexter
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).