flat assembler
Message board for the users of flat assembler.

Index > Compiler Internals > 'err' false positive

Goto page Previous  1, 2
Author
Thread Post new topic Reply to topic
l_inc



Joined: 23 Oct 2009
Posts: 881
l_inc 15 Mar 2012, 23:41
Tomasz Grysztar
Quote:
I do not have any real life example for when this heuristic becomes needed though; I made it as a "just in case" additional precaution.

I think, the recovery from an unstable overflow is possible for any operation the same way as for subtraction and addition. So it seems to be more consistent to do without introducing special cases.

Quote:
In any big program it then may be just any random label from the few thousands. What is the value of such message then?

The value is that it's not any label. It's one of the labels, that depend on some unresolved label of interest. To trace the dependency is the programmer's responsibility.
Quote:
But that would mean, as I already noted previously, that all errors could end up with such message, and thus fasm would ultimately behave as it had just this one error message for all the situations.

I never proposed you to generalize all the messages. Only those where your current more specific error message choice is simply wrong. More general error message is better than an incorrect one.
Post 15 Mar 2012, 23:41
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8356
Location: Kraków, Poland
Tomasz Grysztar 16 Mar 2012, 08:25
l_inc wrote:
I think, the recovery from an unstable overflow is possible for any operation the same way as for subtraction and addition.
My line of thinking was that operations on offsets/addresses more usually involve add/sub and sometimes right shifts/divisions. Before fasm had additional sign bit implemented, those operations did not overflow at all (because assembler had no way to tell whether the overflow was real or not); while multiplication overflowed always with instantaneous error and I simply did not change it.
But now, as I think of it, multiplication can be used to compute the size of an array, where the size of one element is calculated as difference of two labels, and when one of them is forward-referenced, the temporary overflow may occur. So you are right - I can imagine a real application that would only get assembled if fasm allowed temporary multiplication overflow. OK, I'm going to relax this one, too (and same goes for "shl").

l_inc wrote:
I never proposed you to generalize all the messages. Only those where your current more specific error message choice is simply wrong.
And how do you decide whether it is wrong or not?
Post 16 Mar 2012, 08:25
View user's profile Send private message Visit poster's website Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 881
l_inc 17 Mar 2012, 14:38
Tomasz Grysztar
Assuming a completely consistent state could not be achieved, IMHO it's wrong to display an error resulting from using a value, that has been changed within last pass.
Post 17 Mar 2012, 14:38
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8356
Location: Kraków, Poland
Tomasz Grysztar 17 Mar 2012, 14:54
Well, as long as there is any single one value that has been changed and assembler used it, then the error might be result of that value being used (because to know whether error disappears if that value is a bit different, assembler would have to test all the possible variants). So we are back to the problem, that we would get just a general message for any error, when there was at least one unsettled value used during the assembly - and that really wouldn't be much helpful.

And this would also not really help with that "rb x*2" problem, because with current resolver implementation the value x=-1 is in fact consistent between passes (since RB with negative count generates no bytes to output), but it just isn't allowed.
Post 17 Mar 2012, 14:54
View user's profile Send private message Visit poster's website Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 881
l_inc 17 Mar 2012, 16:52
Tomasz Grysztar
Quote:
Well, as long as there is any single one value that has been changed and assembler used it, then the error might be result of that value being used (because to know whether error disappears if that value is a bit different, assembler would have to test all the possible variants).

True. But is it a problem to do only expression-local checks?
E.g., x = 1 shl rva $ - 2*y, where $ has an unsettled value of 64. Therefore it should be easy to derive, that the whole expression has an unsettled value. So the problem is more likely not the overflow. No doubt, there are more complicated cases with dependencies, that cannot be tracked by observing last pass changes.
Btw. I'm not convinced, it would be a good modification. Just trying to understand you reasoning.
Quote:
with current resolver implementation the value x=-1 is in fact consistent between passes (since RB with negative count generates no bytes to output), but it just isn't allowed

Oh. You're right. It also seems to have potential to break some things, if $ was decremented by negative reservations.
Post 17 Mar 2012, 16:52
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8356
Location: Kraków, Poland
Tomasz Grysztar 17 Mar 2012, 20:31
I see that one problem lies in the fact, that the tracking of "unsettled" is not really a good way since any value what depends on values defined somewhere else, could in fact be "unsettled" all the time, even when the value did not change in the last few passes.
We could try to trace the opposite, whether some value is certainly known - for example if you only used numbers in the numerical expression, then the result will always be the same, as so assembler could mark that value as "certain". And if you only had numbers and "certain" symbols in any other expression, then that result could also be "certain"... BUT, the same symbol could be defined in some alternative paths of assembly (created with structural directives), and then it would not really be certain. And even if we had only the direct numbers in some erroneous expression, like "rb -1", it still is not certain that we are in the settled path of assembly - perhaps the right path, which still may be found later, will skip this line...

I think we could try to fix some specific cases, use some heuristics for the most typical usage scenarios, but I doubt we could do it in general. And sometimes the heuristic that made it work nicely for one case, could break it terribly for some other case that earlier was working better... It's all about trade-offs. For example, by making RB directive allocate some constant amount of bytes if provided with negative value, we could make your sample resolve nicely, but then it could make some real programs not get optimized as good as they used to, because the temporary behavior of RB directive would make them generate some long jumps in place where really the short ones would suffice, etc.
Post 17 Mar 2012, 20:31
View user's profile Send private message Visit poster's website Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 881
l_inc 18 Mar 2012, 00:23
Tomasz Grysztar
Quote:
the tracking of "unsettled" is not really a good way since any value what depends on values defined somewhere else, could in fact be "unsettled" all the time, even when the value did not change in the last few passes.

That's what I meant, when talking about "more complicated cases". In such cases fasm would just show the same message as it shows now. So the tracking wouldn't make things worse anyway.
Quote:
I think we could try to fix some specific cases, use some heuristics for the most typical usage scenarios, but I doubt we could do it in general.

No-no. I thought, since you are already tracking unsettled values in order to decide, whether further passes are necessary, it would be an easy fix to check, whether an unsettled value is present in a faulting expression, and this way to make some subset of error messages more reasonable. "Heuristics" and "specific cases" do not sound good to me. Smile I wasn't thinking it's important to make fasm converge to the solution of that rb x*2 example.
Post 18 Mar 2012, 00:23
View user's profile Send private message Reply with quote
asmdev



Joined: 21 Dec 2006
Posts: 18
asmdev 20 Mar 2012, 01:57
format PE64 GUI 5.0
entry start

I'm getting weird error reporting - "value out of range" for instruction "entry start" if I either forget somewhere ":" for label or specify duplicated label that already exists.

1.69.47 fasmw
Post 20 Mar 2012, 01:57
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8356
Location: Kraków, Poland
Tomasz Grysztar 20 Mar 2012, 09:21
Thank you for the report, this was some serious omission. It's corrected now.
Post 20 Mar 2012, 09:21
View user's profile Send private message Visit poster's website Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 881
l_inc 23 Mar 2012, 02:04
Tomasz Grysztar
The mechanism of selecting an error among encountered ones was quite fragile:
Code:
jmp @F
@@:

I'm an innocent line. Blame those both above.
    
Post 23 Mar 2012, 02:04
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8356
Location: Kraków, Poland
Tomasz Grysztar 23 Mar 2012, 04:48
Yes, I don't think this was a good idea after all. It continues to create more problems than it solves. I'm most likely going to revert this to old behavior.
Post 23 Mar 2012, 04:48
View user's profile Send private message Visit poster's website Reply with quote
lostcauz



Joined: 22 Mar 2012
Posts: 13
lostcauz 23 Mar 2012, 11:45
Win7 1.69.47

I'm also getting the non-descriptive error:
entry start
error: undefined symbol 'start'.

when typing mistakes such as:
or eax,;1
Post 23 Mar 2012, 11:45
View user's profile Send private message Visit poster's website Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 881
l_inc 23 Mar 2012, 12:15
Tomasz Grysztar
Quote:
I'm most likely going to revert this to old behavior.

The old way was definitely better. The err directive's usage however still results in undefined behaviour in many cases. Unless you make the overflow errors unrecoverable.
Post 23 Mar 2012, 12:15
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8356
Location: Kraków, Poland
Tomasz Grysztar 23 Mar 2012, 18:29
l_inc wrote:
Unless you make the overflow errors unrecoverable.
It cannot be that general. There are different kinds of overflows and keeping at least some of them recoverable is crucial, otherwise fasm would not be able to resolve even its own sources.

Also, there is nothing specifically related to ERR directive here, it is all about assembler sometimes strangely choosing which route to take - and ERR is very clearly defined to fire when assembler encounters it on its trip. You can think of it as way of telling fasm: if for some reason you try to assemble this, please don't; give up. Wink
Post 23 Mar 2012, 18:29
View user's profile Send private message Visit poster's website Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 881
l_inc 23 Mar 2012, 21:22
Tomasz Grysztar
Quote:
It cannot be that general. There are different kinds of overflows and keeping at least some of them recoverable is crucial, otherwise fasm would not be able to resolve even its own sources.

Then I'm out of suggestions. After all the issue is not that important to be solved at any cost.
Quote:
there is nothing specifically related to ERR directive here

Under "err directive's usage" I meant the official and documented way to generate an unrecoverable error.
Quote:
You can think of it as way of telling fasm: if for some reason you try to assemble this, please don't; give up.

That's clear. And the weakest point here is the part "for some reason" which is sometimes unpredictable and makes also the occurrence of the unrecoverable error unpredictable.
Post 23 Mar 2012, 21:22
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page Previous  1, 2

< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2024, Tomasz Grysztar. Also on GitHub, YouTube.

Website powered by rwasa.