NASM: section start address

  • Follow


I read in section 6.1.3 of the manual:

	6.1.3 Multisection support for the BIN format.
	...
	Nasm creates the section.<secname>.start for each section, which may
be used in your code.

Looking through archive postings about this, it seems that either this
feature does not work, or it works if the section name does not begin
with a dot. I can't get it to work at all, and I think it might be
quite useful for me (assuming it does what I think it does). Can anyone
throw any light on this?

Thanks
Mike

0
Reply spamtrap2 (1628) 1/6/2007 12:38:26 PM

Mike Harrison wrote:
> I read in section 6.1.3 of the manual:
> 
> 	6.1.3 Multisection support for the BIN format.
> 	...
> 	Nasm creates the section.<secname>.start for each section, which may
> be used in your code.
> 
> Looking through archive postings about this, it seems that either this
> feature does not work, or it works if the section name does not begin
> with a dot. I can't get it to work at all, and I think it might be
> quite useful for me (assuming it does what I think it does). Can anyone
> throw any light on this?

Sorry to say, I think it simply doesn't work. Or does it??? I just tried 
it again, and it *does* seem to work. If your section name begins with a 
dot, "section..mysection.start", with two dots, seems to be necessary - 
I'm not sure that's "right"... (but I guess we can live with it)

The "multisection support" has gone through several evolutions. First 
written by Berkus - worked for what he wanted, I guess, but didn't 
please everybody. Then Mike Ter Louw took a stab at it. We designed a 
"specification" first, and everything. Still had some errors, which Mike 
fixed... there are alleged to still be errors, and I *thought* the 
"section.name.start" thing was one of 'em... ("test/multisection.asm" is 
apparently for Berkus' earlier version, and does not currently assemble)

To tell you the truth, I didn't think anyone was using this feature 
much. Peter Johnson, author of Yasm, asked about that in this(?) 
newsgroup a while back - looking for examples - and didn't get any 
response. I guess it's time to revisit this issue. I'll try some more 
tests and try to get back to you...

Best,
Frank

0
Reply Frank 1/7/2007 12:24:38 PM


Frank Kotler wrote:
> Mike Harrison wrote:
> 
>> I read in section 6.1.3 of the manual:
>>
>>     6.1.3 Multisection support for the BIN format.
>>     ...
>>     Nasm creates the section.<secname>.start for each section, which may
>> be used in your code.
>>
>> Looking through archive postings about this, it seems that either this
>> feature does not work, or it works if the section name does not begin
>> with a dot. I can't get it to work at all, and I think it might be
>> quite useful for me (assuming it does what I think it does). Can anyone
>> throw any light on this?
> 
> 
> Sorry to say, I think it simply doesn't work. Or does it??? I just tried 
> it again, and it *does* seem to work. If your section name begins with a 
> dot, "section..mysection.start", with two dots, seems to be necessary - 
> I'm not sure that's "right"... (but I guess we can live with it)
> 
> The "multisection support" has gone through several evolutions. First 
> written by Berkus - worked for what he wanted, I guess, but didn't 
> please everybody. Then Mike Ter Louw took a stab at it. We designed a 
> "specification" first, and everything. Still had some errors, which Mike 
> fixed... there are alleged to still be errors, and I *thought* the 
> "section.name.start" thing was one of 'em... ("test/multisection.asm" is 
> apparently for Berkus' earlier version, and does not currently assemble)
> 
> To tell you the truth, I didn't think anyone was using this feature 
> much. Peter Johnson, author of Yasm, asked about that in this(?) 
> newsgroup a while back - looking for examples - and didn't get any 
> response. I guess it's time to revisit this issue. I'll try some more 
> tests and try to get back to you...

A few more rudimentary tests suggest that it *is* working, after all. 
Can you give us an example of where you're having trouble, Mike?

Best,
Frank

(here's what "works for me", for example)

[map all]

org 100h

section .text
mov ax, section.foo.start
times 10h nop

section .data
db 0

section foo start=200h
db 90h

0
Reply Frank 1/8/2007 1:20:28 AM

Frank Kotler wrote:
> Frank Kotler wrote:
> > Mike Harrison wrote:
> >
> >> I read in section 6.1.3 of the manual:
> >>
> >>     6.1.3 Multisection support for the BIN format.
> >>     ...
> >>     Nasm creates the section.<secname>.start for each section, which may
> >> be used in your code.
> >>
> >> Looking through archive postings about this, it seems that either this
> >> feature does not work, or it works if the section name does not begin
> >> with a dot. I can't get it to work at all, and I think it might be
> >> quite useful for me (assuming it does what I think it does). Can anyone
> >> throw any light on this?
> >
> >
> > Sorry to say, I think it simply doesn't work. Or does it??? I just tried
> > it again, and it *does* seem to work. If your section name begins with a
> > dot, "section..mysection.start", with two dots, seems to be necessary -
> > I'm not sure that's "right"... (but I guess we can live with it)
> >
> > The "multisection support" has gone through several evolutions. First
> > written by Berkus - worked for what he wanted, I guess, but didn't
> > please everybody. Then Mike Ter Louw took a stab at it. We designed a
> > "specification" first, and everything. Still had some errors, which Mike
> > fixed... there are alleged to still be errors, and I *thought* the
> > "section.name.start" thing was one of 'em... ("test/multisection.asm" is
> > apparently for Berkus' earlier version, and does not currently assemble)
> >
> > To tell you the truth, I didn't think anyone was using this feature
> > much. Peter Johnson, author of Yasm, asked about that in this(?)
> > newsgroup a while back - looking for examples - and didn't get any
> > response. I guess it's time to revisit this issue. I'll try some more
> > tests and try to get back to you...
>
> A few more rudimentary tests suggest that it *is* working, after all.
> Can you give us an example of where you're having trouble, Mike?
>
> Best,
> Frank
>
> (here's what "works for me", for example)
>
> [map all]
>
> org 100h
>
> section .text
> mov ax, section.foo.start
> times 10h nop
>
> section .data
> db 0
>
> section foo start=200h
> db 90h

No, it doesn't pass 0200h but 0000h.

     1                                  ;Best,
     2                                  ;Frank
     3                                  ;(here's what "works for me",
for example)
     4                                  [map all foo2.map]
     5                                  org 100h
     6                                  section .text
     7 00000000 B8[0000]                mov ax, section.foo.start
     8 00000003 BB[0400]                mov bx, start2
     9 00000006 90<rept>                times 10h nop
    10                                  section .data
    11 00000000 00                      db 0
    12                                  section foo start=200h
    13 00000000 90                      db 90h
    14 00000001 90                      nop
    15 00000002 90                      nop
    16 00000003 90                      nop
    17                                  start2:
    18 00000004 90                      nop
    19 00000005 90                      nop
    20 00000006 90                      nop

BTW, the solution to Mike's original Macro is in the other thread...

Steve

0
Reply spamtrap 1/8/2007 2:35:44 AM

spamtrap@crayne.org wrote:

....
>>(here's what "works for me", for example)
>>
>>[map all]
>>
>>org 100h
>>
>>section .text
>>mov ax, section.foo.start
>>times 10h nop
>>
>>section .data
>>db 0
>>
>>section foo start=200h
>>db 90h
> 
> 
> No, it doesn't pass 0200h but 0000h.
> 
>      1                                  ;Best,
>      2                                  ;Frank
>      3                                  ;(here's what "works for me",
> for example)
>      4                                  [map all foo2.map]
>      5                                  org 100h
>      6                                  section .text
>      7 00000000 B8[0000]                mov ax, section.foo.start
>      8 00000003 BB[0400]                mov bx, start2
>      9 00000006 90<rept>                times 10h nop
>     10                                  section .data
>     11 00000000 00                      db 0
>     12                                  section foo start=200h
>     13 00000000 90                      db 90h
>     14 00000001 90                      nop
>     15 00000002 90                      nop
>     16 00000003 90                      nop
>     17                                  start2:
>     18 00000004 90                      nop
>     19 00000005 90                      nop
>     20 00000006 90                      nop

Hi Steve,

I'm not sure I see your point. True, the listing file is unhelpful (as 
usual, IME). You got a problem with the binary? I'm looking at (ndisasm 
-o100h multitest.bin>multitest.dis):

00000100  B80002            mov ax,0x200
00000103  BB0402            mov bx,0x204
00000106  90                nop
00000107  90                nop

more "nop"s and many 0s elided.

000001FE  0000              add [bx+si],al
00000200  90                nop
00000201  90                nop
00000202  90                nop
00000203  90                nop
00000204  90                nop
00000205  90                nop
00000206  90                nop

That's what *I* expect to see... I'm not sure what you guys are looking 
for... As Mike observed, there *are* some "issues" with the multisection 
support... Waiting to hear which one he's encountered *this* time :)

> BTW, the solution to Mike's original Macro is in the other thread...

Which solution? We can tell Nasm what it needs to know (perhaps it 
"should" know, but it doesn't), or do it at runtime, or use Fasm. Any 
others?

Best,
Frank

0
Reply Frank 1/8/2007 11:06:49 AM

Frank Kotler wrote:
> spamtrap@crayne.org wrote:
>
> ...
> >>(here's what "works for me", for example)
> >>
> >>[map all]
> >>
> >>org 100h
> >>
> >>section .text
> >>mov ax, section.foo.start
> >>times 10h nop
> >>
> >>section .data
> >>db 0
> >>
> >>section foo start=200h
> >>db 90h
> >
> >
> > No, it doesn't pass 0200h but 0000h.
> >
> >      1                                  ;Best,
> >      2                                  ;Frank
> >      3                                  ;(here's what "works for me",
> > for example)
> >      4                                  [map all foo2.map]
> >      5                                  org 100h
> >      6                                  section .text
> >      7 00000000 B8[0000]                mov ax, section.foo.start
> >      8 00000003 BB[0400]                mov bx, start2
> >      9 00000006 90<rept>                times 10h nop
> >     10                                  section .data
> >     11 00000000 00                      db 0
> >     12                                  section foo start=200h
> >     13 00000000 90                      db 90h
> >     14 00000001 90                      nop
> >     15 00000002 90                      nop
> >     16 00000003 90                      nop
> >     17                                  start2:
> >     18 00000004 90                      nop
> >     19 00000005 90                      nop
> >     20 00000006 90                      nop
>
> Hi Steve,
>
> I'm not sure I see your point. True, the listing file is unhelpful (as
> usual, IME). You got a problem with the binary? I'm looking at (ndisasm
> -o100h multitest.bin>multitest.dis):
>
> 00000100  B80002            mov ax,0x200
> 00000103  BB0402            mov bx,0x204
> 00000106  90                nop
> 00000107  90                nop
>
> more "nop"s and many 0s elided.
>
> 000001FE  0000              add [bx+si],al
> 00000200  90                nop
> 00000201  90                nop
> 00000202  90                nop
> 00000203  90                nop
> 00000204  90                nop
> 00000205  90                nop
> 00000206  90                nop
>
> That's what *I* expect to see... I'm not sure what you guys are looking
> for... As Mike observed, there *are* some "issues" with the multisection
> support... Waiting to hear which one he's encountered *this* time :)
>
> > BTW, the solution to Mike's original Macro is in the other thread...
>
> Which solution? We can tell Nasm what it needs to know (perhaps it
> "should" know, but it doesn't), or do it at runtime, or use Fasm. Any
> others?
>
> Best,
> Frank

Ah, thanks Frank, I didn't know the binary was correct, and the listing
file wasn't.

A solution to his right shift by 16 problem of a non scalar address
type.  The solution involves Casting the address to a scalar value thru
EQU in the section it is defined, and passing that scalar as the
parameter to his macro.

Steve

0
Reply spamtrap 1/8/2007 12:54:55 PM

Frank Kotler wrote:

> (here's what "works for me", for example)
>
> [map all]
>
> org 100h
>
> section .text
> mov ax, section.foo.start
> times 10h nop
>
> section .data
> db 0
>
> section foo start=200h
> db 90h

Well that's very strange... it works for me as well now, both with and
without an initial dot in the section name. In fact, I can't get it to
NOT work. So I don't know what I was doing wrong. It was a while back,
so I can't remember exactly what I was trying to do (and I obviously
found another way to do it) but I certainly remember spending ages
trying different things to get it to accept "section.<name>.start",
without success, including searching Google Groups archives for any
info.

Sorry to have wasted your time :-(

Mike

0
Reply Mike 1/8/2007 5:05:55 PM

Mike Harrison wrote:

....
> So I don't know what I was doing wrong.

In *my* case, the (non)problem was a stupid typo/braino. 
"section.<name>.name" does *not* work! Duh! :)

....
> Sorry to have wasted your time :-(

Never a waste of time to discuss asm. *Somebody's* bound to learn something!

Best,
Frank

0
Reply Frank 1/9/2007 2:06:14 AM

7 Replies
216 Views

(page loaded in 0.079 seconds)

Similiar Articles:













7/22/2012 6:44:08 PM


Reply: