Index
> Compiler Internals > 'err' false positiveGoto page Previous 1, 2 |
| Author |
|
|
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. 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. |
|||
16 Mar 2012, 08:25 |
|
|
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. |
|||
|
17 Mar 2012, 14:38 |
|
|
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. |
|||
|
17 Mar 2012, 14:54 |
|
|
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. |
|||
|
17 Mar 2012, 16:52 |
|
|
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. |
|||
|
17 Mar 2012, 20:31 |
|
|
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.  I wasn't thinking it's important to make fasm converge to the solution of that rb x*2 example. |
|||
|
18 Mar 2012, 00:23 |
|
|
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 |
|||
|
20 Mar 2012, 01:57 |
|
|
Tomasz Grysztar 20 Mar 2012, 09:21
Thank you for the report, this was some serious omission. It's corrected now.
|
|||
|
20 Mar 2012, 09:21 |
|
|
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.
|
|||
|
23 Mar 2012, 02:04 |
|
|
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.
|
|||
|
23 Mar 2012, 04:48 |
|
|
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 |
|||
|
23 Mar 2012, 11:45 |
|
|
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. |
|||
|
23 Mar 2012, 12:15 |
|
|
Tomasz Grysztar 23 Mar 2012, 18:29
l_inc wrote: Unless you make the overflow errors unrecoverable. 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.  |
|||
|
23 Mar 2012, 18:29 |
|
|
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. |
|||
|
23 Mar 2012, 21:22 |
|
| Goto page Previous 1, 2 < Last Thread | Next Thread > |
Forum Rules:
|