-l appears nonfunctional on m68k-elf-as 2.14.90.0.4 20030523

[gcc]

Given the following source code:
        .text
foo:
        addq.l #1,foovar
        move.l foovar,%d0
        rts

m68k-elf-as -l -al produces the following listing:
   1                            .text
   2                    foo:
   3 0000 52B9 0000             addq.l #1,foovar
   3      0000 
   4 0006 2039 0000             move.l foovar,%d0
   4      0000 
   5 000c 4E75                  rts

Note how the reference to the undefined symbol "foovar" tales 32 bits.

If I change the source code to explicitly use the :w modifier:
        .text
foo:
        addq.l #1,foovar:w
        move.l foovar:w,%d0
        rts

Then I get the desired outpu:
   1                            .text
   2                    foo:
   3 0000 52B8 0000             addq.l #1,foovar:w
   4 0004 2038 0000             move.l foovar:w,%d0
   5 0008 4E75                  rts

The documentation seems to say that this should work.

I note that the -l option is not documeted in the --target-help
message, although it is in the code and seems to do something.

I tried to follow what was going on, but I get a litle lost
tracing though the code.

Should there be a reference to flag_short_refs in the ABSL/CASE_UNSPEC
handling aroung line 7148 of tc-m68k.c?

(The goal, of course, is to generate smaller/faster object code when the
data segment fits in he first 32K.  I can do i, I suppose, with really
rude C code of the form
        extern int foovar asm("foovar:w");
but that seriously clutters the code, requires special definition kludges,
and leaves the static variable problem.)

Thanks a lot for a great tool!


@item -l
You can use the @samp{-l} option to shorten the size of references to undefined
symbols.  If you do not use the @samp{-l} option, references to undefined
symbols are wide enough for a full @code{long} (32 bits).  (Since
@address@hidden cannot know where these symbols end up, @address@hidden can
only allocate space for the linker to fill in later.  Since @address@hidden
does not know how far away these symbols are, it allocates as much space as it
can.)  If you use this option, the references are only one word wide (16 bits).
This may be useful if you want the object file to be as small as possible, and
you know that the relevant symbols are always less than 17 bits away.