call far ptr ds:[var] or call far ptr es:var not rejected (and therefore wrongly assembled)

[stsp]

I was stumbled at why my
code doesn't work. After some
disasm, it appears that
call far ptr ds:[var]
is assembled into a direct
far call with bogus segment.
I've found that I had to write:
call fword ptr ds:[var]
instead, and that works fine.

Still I think wrongly assembling
call far ptr ds:[var]
is not good. Maybe assembler
should just error on that?

[jmalak]

Sorry, I need compilable sample and command line for assembler.
Also what encodding you get and what encoding you expect.
It is without any context (what segment what options etc.)
especialy far call is encoded by context.

[stsp]

Sure, here is the fully automated
reproducer. Just run make.

ow.tar.gz

[stsp]

Here's the sample output of
the reproducer:

$ make
owcc -b dos4g -o bad.o -c bad.S
owcc -b dos4g -o good.o -c good.S
This is a bad disasm
wdis bad.o | grep call
0000  3E 9A 00 00 00 00 00 00		call		L$1
This is a good disasm
wdis good.o | grep call
0000  FF 1D 00 00 00 00			call		fword ptr L$1

As you can see, in the first
example we have a direct
call, not indirect one. Linker
will also patch in the bogus
segment there.

[jmalak]

It is not a problem.
your "bad" example specify direct far call to label L$1 (entry)

_DATA SEGMENT BYTE PUBLIC 'DATA'

entry:
entry_ip: DD 0
entry_cs: DD 0

_DATA ENDS

.386p
_TEXT SEGMENT BYTE PUBLIC 'CODE'
_main PROC NEAR
    call far ptr ds:[entry]
    ret
_main ENDP
_TEXT ENDS
END

Module: bad

Segment: _DATA BYTE USE32 00000008 bytes
0000                            L$1:
0000  00 00 00 00 00 00 00 00                         ........

Segment: _TEXT BYTE USE32 00000009 bytes
0000                            _main:
0000  3E 9A 00 00 00 00 00 00           call            L$1
0008  C3                                ret

Routine Size: 9 bytes,    Routine Base: _TEXT + 0000

No disassembly errors

your "good" example specify indirect far call by variable L$1 (entry)

_DATA SEGMENT BYTE PUBLIC 'DATA'

entry:
entry_ip: DD 0
entry_cs: DD 0

_DATA ENDS

.386p
_TEXT SEGMENT BYTE PUBLIC 'CODE'
_main PROC NEAR
    call fword ptr ds:[entry]
    ret
_main ENDP
_TEXT ENDS
END

Module: good

Segment: _DATA BYTE USE32 00000008 bytes
0000                            L$1:
0000  00 00 00 00 00 00 00 00                         ........

Segment: _TEXT BYTE USE32 00000007 bytes
0000                            _main:
0000  FF 1D 00 00 00 00                 call            fword ptr L$1
0006  C3                                ret

Routine Size: 7 bytes,    Routine Base: _TEXT + 0000

No disassembly errors

I don't see any problem.

[stsp]

The problem is that in both
cases I specify [var].
You can even edit bad.S
and remove [], so that this
remains:
call far ptr ds:entry.
It will assemble it exactly the
same way. So in my example
it simply ignores []. I suppose
it should error out, because
[] cannot be in a direct call.
But simply ignoring [] is not a
solution.

[stsp]

And even call far ptr ds:entry is
wrong. The correct syntax for the
direct call is:
call far ptr 0x7f,entry
where 0x7f is an absolute segment.
You can't use register-based segment
in a direct far call. But OW allows.

[jmalak]

I disagree with you, relevant is "far ptr" and "fword ptr" not [].
[] is relevant in case if you don't specify "far ptr" or "fword ptr".
It is about operator precedence.

[jmalak]

I don't understand your problem.
Probably you are expecting different syntax from different assembler.
May be you are expecting syntax error and WASM don't report it but encoding of direct and indirect call is correct.

[stsp]

It is about operator precedence.

No, its not a precedence, because
whether or not [] is present, the
assembly is identical, meaning
[] was just ignored. But its an invalid
syntax. Ignoring invalid syntax is
not always good.

Lets see how nasm behaves:

SEGMENT _DATA

entry:
entry_ip: DD 0
entry_cs: DD 0

SEGMENT _TEXT
_main:
    call far ds:entry
    ret

good.s:9: error: invalid combination of opcode and operands

But this works:
call far [ds:entry]

Also this works:
call 7fh:entry

But this doesn't:
call far [7fh:entry]
good.s:9: error: invalid segment override

So as you can see, nasm never ignores
[]. It correctly errors out when []
cannot be applied.

May be you are expecting syntax error and WASM don't report it but encoding of direct and indirect call
is correct.

But how can this be correct:
call far ptr es:entry?
There is simply no possibility
in x86 to use segment registers
in a direct far jump or call. How
do you suppose to assemble that
in any "correct" way? The only way
to assemble the far jump, is
by explicitly specifying the segment
value, like:
call far ptr 0x7f,entry
And what happens in case of
call far es:entry assembled
with wasm, is that the segment
is always 0! Simply because there
is no such instruction, you can't
really use ES register here.

[stsp]

So lets clarify, as I am now
mixing 2 different problems
into 1.

1 problem is that [] is simply
ignored, not errored out.

2 problem is that wasm allows
this:
call far es:entry.
But there is no such instruction
in x86, so as the result, we have
the equivalent of this:
call far 0,entry
which means that segment is
always 0, no matter what ES
contained.

[jmalak]

You are right that WASM diagnostics is not good and need improvement.

[stsp]

Thank you. :)
It doesn't matter whether you
fix it or not, at least for me.
If we agree, its already enough,
as my code now fixed anyway.

Btw I suggested you a small
patch to clib in another ticket.
Not sure if you have seen it or not.

[jmalak]

Please, if you have any change to OW then create pull request with such change (it starts CI build which check build on all platforms etc.). CI build create full snaphot with you change and it is available for download (for 10 days I think).

[stsp]

Ok, I will do such a PR, but the
problem is that it will remain
untested on OW. I tested it only
on the code that was "ripped off"
from OW source tree. This is why
I didn't proceed with the PR
initially.
But I'll do, and add the "untested"
note.