Assembler messages

Assembler messages

[Shaun Jackman]

../../arch-at91/syscall_handler.S: Assembler messages:
../../arch-at91/syscall_handler.S:25: Error: internal_relocation 
(type: OFFSET_IMM) not fixed up

... and line 25 says...
	ldr lr, syscall_lr

... which I think means that syscall_lr is out of range. So if I'm 
correct, my wish-list item requests that this error message state why 
the fix-up failed (presumably because this memory address is out of 
range), what the range is, and by what amount the range was exceeded.

Thanks!
Shaun

Re: Assembler messages

[Ben Elliston]

Shaun Jackman <sjackman@telus.net> writes:

> correct, my wish-list item requests that this error message state
> why the fix-up failed (presumably because this memory address is out
> of range), what the range is, and by what amount the range was
> exceeded.

In that case, please file a bug report in Bugzilla.

Ben

Re: Assembler messages

[Nick Clifton]

Hi Shaun,
> ../../arch-at91/syscall_handler.S: Assembler messages:
> ../../arch-at91/syscall_handler.S:25: Error: internal_relocation 
> (type: OFFSET_IMM) not fixed up
> 
> ... and line 25 says...
> 	ldr lr, syscall_lr
> 
> ... which I think means that syscall_lr is out of range. So if I'm 
> correct, my wish-list item requests that this error message state why 
> the fix-up failed (presumably because this memory address is out of 
> range), what the range is, and by what amount the range was exceeded.
> 
> Thanks!
> Shaun

Re: Assembler messages

[Nick Clifton]

Hi Shaun,

> ../../arch-at91/syscall_handler.S: Assembler messages:
> ../../arch-at91/syscall_handler.S:25: Error: internal_relocation 
> (type: OFFSET_IMM) not fixed up
> 
> ... and line 25 says...
> 	ldr lr, syscall_lr
> 
> ... which I think means that syscall_lr is out of range. So if I'm 
> correct, my wish-list item requests that this error message state why 
> the fix-up failed (presumably because this memory address is out of 
> range), what the range is, and by what amount the range was exceeded.

Please feel free to submit a patch that does this.

Cheers
	 Nick

Re: Assembler messages

[Richard Earnshaw]

On Thu, 2004-06-10 at 15:42, Nick Clifton wrote:
> Hi Shaun,
> 
> > ../../arch-at91/syscall_handler.S: Assembler messages:
> > ../../arch-at91/syscall_handler.S:25: Error: internal_relocation 
> > (type: OFFSET_IMM) not fixed up
> > 
> > ... and line 25 says...
> > 	ldr lr, syscall_lr
> > 
> > ... which I think means that syscall_lr is out of range. So if I'm 
> > correct, my wish-list item requests that this error message state why 
> > the fix-up failed (presumably because this memory address is out of 
> > range), what the range is, and by what amount the range was exceeded.
> 
> Please feel free to submit a patch that does this.

Err, I think in this case it was expecting syscall_lr to be an assembly
time literal.  If the literal isn't found then you'll get the cited
message.

Re: Assembler messages

[Shaun Jackman]

On Thu June 10, 2004 08h49, Richard Earnshaw wrote:
> On Thu, 2004-06-10 at 15:42, Nick Clifton wrote:
> > Hi Shaun,
> >
> > > ../../arch-at91/syscall_handler.S: Assembler messages:
> > > ../../arch-at91/syscall_handler.S:25: Error:
> > > internal_relocation (type: OFFSET_IMM) not fixed up
> > >
> > > ... and line 25 says...
> > > 	ldr lr, syscall_lr
> > >
> > > ... which I think means that syscall_lr is out of range. So if
> > > I'm correct, my wish-list item requests that this error message
> > > state why the fix-up failed (presumably because this memory
> > > address is out of range), what the range is, and by what amount
> > > the range was exceeded.
> >
> > Please feel free to submit a patch that does this.
>
> Err, I think in this case it was expecting syscall_lr to be an
> assembly time literal.  If the literal isn't found then you'll get
> the cited message.

I don't think that's the case. I was able to fix my problem by adding 
a step of indirection:

	ldr lr, =syscall_lr
	ldr lr, [lr]

Cheers,
Shaun

Re: Assembler messages [PATCH]

[Shaun Jackman]

I changed the error message so that it is correct for the case that
I am seeing. I do not know if this is correct for every case.

Please cc me in your reply. Cheers!
Shaun


2004-06-10  Shaun Jackman  <sjackman@debian.org>

	* gas/config/tc-arm.c (tc_gen_reloc): Provide a descriptive error
	message when a PC relative relocation is out of range.

--- tc-arm.c-   2004-05-17 12:36:08.000000000 -0700
+++ tc-arm.c    2004-06-10 17:09:42.000000000 -0700
@@ -12830,7 +12830,8 @@
        }

       as_bad_where (fixp->fx_file, fixp->fx_line,
-                   _("internal_relocation (type: OFFSET_IMM) not fixed up"));
+             _("symbol `%s' is out of range (4096 bytes from the program counter)"),
+             S_GET_NAME (fixp->fx_addsy));
       return NULL;

     default:


On Thu June 10, 2004 07h42, you wrote:
> Hi Shaun,
>
> > ../../arch-at91/syscall_handler.S: Assembler messages:
> > ../../arch-at91/syscall_handler.S:25: Error: internal_relocation
> > (type: OFFSET_IMM) not fixed up
> >
> > ... and line 25 says...
> > 	ldr lr, syscall_lr
> >
> > ... which I think means that syscall_lr is out of range. So if
> > I'm correct, my wish-list item requests that this error message
> > state why the fix-up failed (presumably because this memory
> > address is out of range), what the range is, and by what amount
> > the range was exceeded.
>
> Please feel free to submit a patch that does this.
>
> Cheers
> 	 Nick

Re: Assembler messages [PATCH]

[Richard Earnshaw]

On Fri, 2004-06-11 at 02:01, Shaun Jackman wrote:
> I changed the error message so that it is correct for the case that
> I am seeing. I do not know if this is correct for every case.
> 
> Please cc me in your reply. Cheers!
> Shaun
> 
> 
> 2004-06-10  Shaun Jackman  <sjackman@debian.org>
> 
> 	* gas/config/tc-arm.c (tc_gen_reloc): Provide a descriptive error
> 	message when a PC relative relocation is out of range.
> 
> --- tc-arm.c-   2004-05-17 12:36:08.000000000 -0700
> +++ tc-arm.c    2004-06-10 17:09:42.000000000 -0700
> @@ -12830,7 +12830,8 @@
>         }
> 
>        as_bad_where (fixp->fx_file, fixp->fx_line,
> -                   _("internal_relocation (type: OFFSET_IMM) not fixed up"));
> +             _("symbol `%s' is out of range (4096 bytes from the program counter)"),
> +             S_GET_NAME (fixp->fx_addsy));
>        return NULL;

No, that isn't right.

Consider this case:

.text
l:
        ldr     r0, x

X isn't defined at all, so it's not correct to say it's out of range.

R.

Re: Assembler messages [PATCH]

[Richard Earnshaw]

On Fri, 2004-06-11 at 10:46, Richard Earnshaw wrote:
> On Fri, 2004-06-11 at 02:01, Shaun Jackman wrote:
> > I changed the error message so that it is correct for the case that
> > I am seeing. I do not know if this is correct for every case.
> > 
> > Please cc me in your reply. Cheers!
> > Shaun
> > 
> > 
> > 2004-06-10  Shaun Jackman  <sjackman@debian.org>
> > 
> > 	* gas/config/tc-arm.c (tc_gen_reloc): Provide a descriptive error
> > 	message when a PC relative relocation is out of range.
> > 
> > --- tc-arm.c-   2004-05-17 12:36:08.000000000 -0700
> > +++ tc-arm.c    2004-06-10 17:09:42.000000000 -0700
> > @@ -12830,7 +12830,8 @@
> >         }
> > 
> >        as_bad_where (fixp->fx_file, fixp->fx_line,
> > -                   _("internal_relocation (type: OFFSET_IMM) not fixed up"));
> > +             _("symbol `%s' is out of range (4096 bytes from the program counter)"),
> > +             S_GET_NAME (fixp->fx_addsy));
> >        return NULL;
> 
> No, that isn't right.
> 
> Consider this case:
> 
> .text
> l:
>         ldr     r0, x
> 
> X isn't defined at all, so it's not correct to say it's out of range.

And this one.  In this case the PC isn't used at all:

.text
l:
        ldr     r0, [r0, #x]

Re: Assembler messages [PATCH]

[Shaun Jackman]

Ah! Sorry. I understand your original post to me now. Is it at all 
possible to generate the following form?

[a.s]
.text
a:
.word 0

[b.s]
.text
b:
	ldr r0, a

To me, just because the symbol and the referencer are in different 
files shouldn't end the world. That's why we have a linker. If you 
merge the two files it works just fine.

[ab.s]
.text
a:
.word 0
b:
	ldr r0, a

I noticed that if the symbol and the referencer are in different 
sections we also see this same error:

[c.s]
.data
a:
.word 0
.text
b:
	ldr r0, a

And finally, my initial conclusion was entirely incorrect.

[d.s]
.text
a:
.word 0
.space 4096, 0
b:
        ldr r0, a

$ arm-elf-as d.s
d.s: Assembler messages:
d.s:6: Error: bad immediate value for offset (4108)

So, that error message works just fine.

Can we change the error message then to...
	"`%s' must be defined in this file"
and a check for the second case is needed:
	"`%s' must be defined in the same section"

Cheers,
Shaun


> No, that isn't right.
>
> Consider this case:
>
> .text
> l:
>         ldr     r0, x
>
> X isn't defined at all, so it's not correct to say it's out of
> range.
>
> R.

RE: Assembler messages [PATCH]

[Dave Korn]

> -----Original Message-----
> From: binutils-owner On Behalf Of Shaun Jackman
> Sent: 11 June 2004 17:21

> Ah! Sorry. I understand your original post to me now. Is it at all 
> possible to generate the following form?
> 
> [a.s]
> .text
> a:
> .word 0
> 
> [b.s]
> .text
> b:
> 	ldr r0, a
> 
> To me, just because the symbol and the referencer are in different 
> files shouldn't end the world. That's why we have a linker. If you 
> merge the two files it works just fine.

  Yes, that'll work fine.  In the prior example, the symbol X was assumed
not to actually be defined anywhere else, I assume.

> and a check for the second case is needed:
> 	"`%s' must be defined in the same section"

  When gas detects that two symbols are in different sections and the abi
doesn't support the necessary reloc, it emits the following message
(gas/write.c:fixup_segment)

Error: can't resolve `.text' {.text section} - `.L13' {.rodata section}

  May I suggest it would be good to make the messages consistent between
assembler and linker?



    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....
 

Re: Assembler messages

[Shaun Jackman]

> > [a.s]
> > .text
> > a:
> > .word 0
> >
> > [b.s]
> > .text
> > b:
> > 	ldr r0, a
> >
> > To me, just because the symbol and the referencer are in
> > different files shouldn't end the world. That's why we have a
> > linker. If you merge the two files it works just fine.
>
>   Yes, that'll work fine.  In the prior example, the symbol X was
> assumed not to actually be defined anywhere else, I assume.

Ah, but it doesn't work, and I don't understand why.

$ arm-elf-gcc -c a.s b.s
b.s: Assembler messages:
b.s:3: Error: internal_relocation (type: OFFSET_IMM) not fixed up
$ cat a.s b.s > ab.s
$ arm-elf-gcc -c ab.s
$

Can this be made to work?

> > and a check for the second case is needed:
> > 	"`%s' must be defined in the same section"
>
>   When gas detects that two symbols are in different sections and
> the abi doesn't support the necessary reloc, it emits the following
> message (gas/write.c:fixup_segment)
>
> Error: can't resolve `.text' {.text section} - `.L13' {.rodata
> section}
>
>   May I suggest it would be good to make the messages consistent
> between assembler and linker?

I found that the assembler produced the same cryptic message.

$ cat > c.s
.data
a:
.word 0
.text
b:
        ldr r0, a
$ arm-elf-gcc -c c.s
c.s: Assembler messages:
c.s:6: Error: internal_relocation (type: OFFSET_IMM) not fixed up

I'd like to replace all occurrences of this message this a message 
explaining why the assembler was unable to fix up the relocation.

Cheers,
Shaun

RE: assembler messages...

[David Korn]

>Can anyone let me know what means "Assembler messages: for 
>reading.open :NO such
> file or directory" ?

  It means you've got the wrong kind of line ends in your makefile, and 
somehow the carriage return (because DOS uses CR-LF, but Unix and Cygwin
expect only LF) has been treated as a filename, so when the assembler tries
to open the file it fails (you cannot have a file named CR)

--------
      Cannot open <filename> for reading.
<filename>:  No such file or directory
-----------

it prints the carriage return instead of the filename, giving

--------
      Cannot open 
 for reading.

:  No such file or directory
-----------

except that since this is a CR without LF, the second part of each line
prints on top of the first part, so you see

--------
 for reading.open 
:  No such file or directory
-----------

  When you're building under Cygwin it's always a good idea to keep your
source code in a directory that is mounted in text mode (as long as there
aren't any binary files going in there!).  Alternatively you can create a
file called /bin/dos2unix, containing this code:

  #!/bin/sh
  cp $1 $1.dos && tr -d '\015' <$1.dos >$1 && rm $1.dos

and make it runnable by executing

  chmod ugo+x /bin/dos2unix

and you can then say 'dos2unix <filename>' any time you get this problem
again.

     DaveK
-- 
 All your base are belong to us!


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************

assembler messages...

[luca.spinacci]

Hi all,

Compiling with a make file a tree of C/C++ files I got this message:

$ make all_PICo
making all object PIC files in ./ami...
make -i ami.o ami_ostream.o amiacl.o amiacl.smdb.o amitables.o amitables.smdb.o
batch.o command_ami.o command_choice.o command_dir.o command_smdb.o fmtr.o;
making ami.o...
Assembler messages:
 for reading.open
: No such file or directory
...

The make command to compile files in the ./ami directory is:

$(GCC_PATH)/gcc $(INC) $(ASS_OPTS) $<

or in a clearer way

C:/cygwin/tools/H-i686-pc-cygwin/powerpc-eabi/bin/gcc  -I../_mysys -I../include
-I../platform -I../platform/psos -I../platform/generic  -I.. -c -mcpu=860
-fno-gnu-linker -fpic -x c++ ami.cc

Can anyone let me know what means "Assembler messages: for reading.open :NO such
 file or directory" ?

Thank you in advance,
Luca.