struc PSX_EXE_HEADER
.id: resd 2 ;0x00
.text: resd 1
.data: resd 1
.pc0: resd 1 ;0x10
.gp0: resd 1
.t_addr: resd 1 ;0x18
.t_size: resd 1 ;0x1c
.d_addr: resd 1
.d_size: resd 1
.b_addr: resd 1
.b_size: resd 1
.s_addr: resd 1 ;0x30
.s_size: resd 1 ;0x34
.SavedSP: resd 1
.SavedFP: resd 1
.SavedGP: resd 1
.SavedRA: resd 1
.SavedS0: resd 1
endstruc
[section .text public use32 class=CODE align=16]
mov eax,edx
this code generate warning
warning: segment attributes specified on redeclaration of
segment: ignoring
Logged In: NO
I'm assuming that you're using -f obj to assemble this.
Since .text is the default segment, your [SEGMENT]
directive isn't creating the .text segment, but merely
re-opening it.
And when a segment is re-opened, NASM throws a
warning if there are any arguments other than just the
segment name.
Why? Because it reminds the user that he or she is
merely re-opening a segment, which means that all
those attributes he or she specified won't take effect.
Instead the segment will stick with the attributes from
the original definition.
Though NASM could be improved to check each and
every attribute, and only throw the warning if there is
an actual mismatch, this would require a lot of code,
and introduce more complexity.
PS: Note that the STRUC in this example does enter
absolute space, and that the ENDSTRUC does return
to __SECT__ = "[section .text]" -- which won't cause
the warning, as there are no attributes.
Logged In: NO
it was compiled using -f elf
"Note that the STRUC in this example does enter
absolute space, and that the ENDSTRUC does return
to __SECT__ = "[section .text]" -- which won't cause
the warning, as there are no attributes."
I thinking that i define struc template. If it wrong, than how can I define
struc tamplate.
Logged In: NO
With regard to this issue, the ELF and the OBJ format behave
identically.
Of course you can always write your own structure support
macros. :-)
You may want to check the XSTRUC stuff that was posted to
one of the NASM forums a while ago.
Btw, this issue could also be addressed by changing the
SEGMENT macro, so that it accepts two parameters,
whereas the first parameter would be the segment name, and
the second parameter would lump all of the attributes. This
would allow __SEC__ to be defined with just the segment
name, which in turn would avoid the warning.
However, changing the SEGMENT macro would break
compatibility with prior NASM versions. So this looks like a
minor design flaw we will have to live with...
Logged In: YES
user_id=68913
... thought I posted this before... There's a "workaround"
for this annoyance.
section .text use32 align=4 class=code ; whatever...
section .text
Now __SECT__ is just ".text", and Nasm won't whine when it
sees it.
The fact that ".text" is used as a structure member name...
I don't *think* that'll cause a problem, but you might want
to try something else...
Best,
Frank