[GLOBAL] does check for valid identifiers.
[GLOBAL] must be used before the label is defined.
[GLOBAL] doesn't require the label to be defined afterwards.
Put another way, I think [GLOBAL] is working as expected.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
>[GLOBAL] doesn't require the label to be defined afterwards.
That is exactly what I don't expect (or: want) [GLOBAL] to do. I want to notice it by an error or warning if I used a [GLOBAL] line that isn't written into the binary/object because there's no label with that name found.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In essence the label manager would need to iterate
over all labels at the end of the final pass, and
emit a suppressible warning for the ones which are
marked as GLOBAL_BIT but not DEFINED_BIT. (Making
it a suppressible warning means that this overhead
only kicks in when a user explicitly requests it.
Defaulting the warning to "disabled" ensures back-
wards compatibility with prior versions.)
I would use "orphan-globals" to match the existing
"orphan-labels" warning.
(That said, this is a feature request, not a bug.)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The attached sample changes incur a compare+branch
penalty for every label. To eliminate it, the state
of this warning would have to be made available to
the label manager. Is that worth it? You decide.
File Added: changes.txt
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2008-08-06
Logged In: YES
user_id=73628
Originator: NO
If we add this feature for global, then is seems only reasonable that we do the same for extern and common. And why not go all the way, and report all orphan labels, as well? In fact, my preference would be to offer an optional cross-reference listing of all symbols, showing the symbol type, the number of the line on which it was defined, and numbers of all lines on which it was referenced.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> If we add this feature for global, then
> is seems only reasonable that we do the
> same for extern and common.
You would need REFERENCED_BIT in labels
to track whether an [EXTERN] or [COMMON]
label was ever referenced. (So that you
can warn for unused [EXTERN] or [COMMON]
labels at the end.)
> And why not go all the way, and report
> all orphan labels, as well?
Dito.
I'll take a closer look, to see if there
are any hidden corner cases...
> In fact, my preference would be to offer
> an optional cross-reference listing of
> all symbols, showing the symbol type, the
> number of the line on which it was defined,
> and numbers of all lines on which it was
> referenced.
Define "line number". :-)
An overall line number doesn't seem useful.
Although a list file line number might be.
Any per-file line number would require that
the file(s) be tracked as well.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> Any per-file line number would require that
> the file(s) be tracked as well.
And that the preprocessor is active -- else
it is just one big file from the assembler's
perspective.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2008-08-07
Logged In: YES
user_id=73628
Originator: NO
The issues which nasm64developer raises are real, but not that difficult to handle. For example, tracking symbol references is not that much different than tracking relocation entries, which most of the output modules already do.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Logged In: NO
[GLOBAL] does check for valid identifiers.
[GLOBAL] must be used before the label is defined.
[GLOBAL] doesn't require the label to be defined afterwards.
Put another way, I think [GLOBAL] is working as expected.
Logged In: NO
>[GLOBAL] doesn't require the label to be defined afterwards.
That is exactly what I don't expect (or: want) [GLOBAL] to do. I want to notice it by an error or warning if I used a [GLOBAL] line that isn't written into the binary/object because there's no label with that name found.
Logged In: YES
user_id=804543
Originator: NO
In essence the label manager would need to iterate
over all labels at the end of the final pass, and
emit a suppressible warning for the ones which are
marked as GLOBAL_BIT but not DEFINED_BIT. (Making
it a suppressible warning means that this overhead
only kicks in when a user explicitly requests it.
Defaulting the warning to "disabled" ensures back-
wards compatibility with prior versions.)
I would use "orphan-globals" to match the existing
"orphan-labels" warning.
(That said, this is a feature request, not a bug.)
sample changes
Logged In: YES
user_id=804543
Originator: NO
The attached sample changes incur a compare+branch
penalty for every label. To eliminate it, the state
of this warning would have to be made available to
the label manager. Is that worth it? You decide.
File Added: changes.txt
Logged In: YES
user_id=73628
Originator: NO
If we add this feature for global, then is seems only reasonable that we do the same for extern and common. And why not go all the way, and report all orphan labels, as well? In fact, my preference would be to offer an optional cross-reference listing of all symbols, showing the symbol type, the number of the line on which it was defined, and numbers of all lines on which it was referenced.
Logged In: YES
user_id=804543
Originator: NO
> If we add this feature for global, then
> is seems only reasonable that we do the
> same for extern and common.
You would need REFERENCED_BIT in labels
to track whether an [EXTERN] or [COMMON]
label was ever referenced. (So that you
can warn for unused [EXTERN] or [COMMON]
labels at the end.)
> And why not go all the way, and report
> all orphan labels, as well?
Dito.
I'll take a closer look, to see if there
are any hidden corner cases...
> In fact, my preference would be to offer
> an optional cross-reference listing of
> all symbols, showing the symbol type, the
> number of the line on which it was defined,
> and numbers of all lines on which it was
> referenced.
Define "line number". :-)
An overall line number doesn't seem useful.
Although a list file line number might be.
Any per-file line number would require that
the file(s) be tracked as well.
Logged In: YES
user_id=804543
Originator: NO
> Any per-file line number would require that
> the file(s) be tracked as well.
And that the preprocessor is active -- else
it is just one big file from the assembler's
perspective.
Logged In: YES
user_id=73628
Originator: NO
The issues which nasm64developer raises are real, but not that difficult to handle. For example, tracking symbol references is not that much different than tracking relocation entries, which most of the output modules already do.