Re: Multi-section bin code users: RFC


Peter Johnson wrote:
I'm currently working on adding support for NASM-style multi-section
binary output to Yasm, but I'm having trouble finding use examples on
the web (to use as more complex testcases). About the only ones I've
found thus far are some disassembly outputs (of the Blaster worm, of all
things!), bug reports to NASM (from hpa and others), and some of the
initial discussion on nasm-devel about adding this feature to NASM.

Is multi-section binary really not that widely used?

Not widely used. But I use it abit. One reason it is not widely used
is because some sort of scheme must be devised to manage loading the
sections into the segment registers. Seems like most are using a flat
address space, whereas sections are more segments based. Also, few are
doing pure assembly so the HLL obj form & tools dictate what is done
also.

Here is a work in progress...
ftp://project001.serveftp.net/nasmwork/DiskView/
DiskView.nsm is a bin project designed to be loaded into a debugger and
run. It is in the rough but will read the tracks and sectors off a 3
1/2 in. floppy using the RomBios Int13h.
and dump them to the display.

- NASM Map file
---------------------------------------------------------------

Source file: diskview.nsm
Output file: diskview.bin

-- Program origin
-------------------------------------------------------------

00000000

-- Sections (summary)
---------------------------------------------------------

Vstart Start Stop Length Class Name
00000000 00000000 00000000 00000000 progbits .text
00000000 00000000 00000310 00000310 progbits .cseg
00000000 00000310 000003D0 000000C0 progbits .dseg
00000000 000003D0 000027E0 00002410 progbits .eseg
00000000 000027E0 00002860 00000080 progbits .sseg

It is intended to be loaded under DEBUG.EXE operating in the Command
Prompt dialog box.
To run it under debug, since debug fixes the CS to the PSP and IP to
0100, RIP ip to zero and RCS to Current Value + 10h, the start of the
code of diskview.bin. Now you can execute it, G. The program
self-initializes the Segment Registers according to the named sections
above, not .COM like at all. It does this because it 'knows itself'
the CS value, and thru the use of nasm macros, the developed length of
each section, and their ordering. In that narrow sense, it is a
self-loading .bin example. The program is in the rough, it doesn't
echo back user input, and there is a bug or two left to be squashed.
Some floppy diskette must be in the A: drive also. Normally I wouldn't
offer it as an example, but I am sympathetic to your plight for .bin
section examples. It was a hack to diagnose floppy sector content
issues.

Another example:
ftp://project001.serveftp.net/nasmwork/NASM4CPM86/

- NASM Map file
---------------------------------------------------------------

Source file: prgmhead.nsm
Output file: prgmhead.cmd

-- Program origin
-------------------------------------------------------------

00000000

-- Sections (summary)
---------------------------------------------------------

Vstart Start Stop Length Class Name
00000000 00000000 00000080 00000080 progbits .text
00000000 00000080 00000130 000000B0 progbits .cseg
00000000 00000130 00000300 000001D0 progbits .dseg
00000000 00000300 00000380 00000080 progbits .eseg
00000000 00000380 00000400 00000080 progbits .sseg
00000000 00000000 00000080 00000080 nobits .x1
00000000 00000000 00000100 00000100 nobits .x2
00000000 00000000 00000400 00000400 nobits .x3
00000000 00000000 00001000 00001000 nobits .x4

The above is a cross compile of a stub example program for the CP/M-86
OS. I did this as a proof of concept. As you can see there are four
progbits sections and four nobits sections, these are standard named
sections for the CP/M-86 OS Loader, and BINCMD.MAC is the macro which
creates the Header Record [sort of a PSP] which the OS Loader expects
for loading an executable .cmd file.


Or is it just that
the advanced features I'm looking for use of (vfollows, vstart, etc)
aren't?

As you can see, I use vstart=0 for each named section.

Or is everyone using a "real" object format like RDOFF2 or ELF
instead, and linking it into binary output?

Yes, it seems so.

Or is NASM's support buggy
in such a way that the advanced features aren't very useful?

symbols report in a map file is buggy. I stumbled onto a work around
this weekend--
[MAP myfile.MAP]
[MAP symbols myfile.SYM] actually appends the symbols to myfile.map

If you have some multi-section binary code to share, please send it my
direction!

I'd be curious to hear what other feedback you get.

More importantly, are there features that you'd like to see supported
and/or changed in the multi-section binary design? If so, I'll see if I
can implement them in Yasm.

And as always, feel free to report any bugs you find in Yasm on the Yasm
Trac or via email. You may see me posting here more frequently in the
future as I'd like to see more community involvement in Yasm's development.

Thanks!

--
Peter Johnson
http://www.tortall.net/projects/yasm/

Steve

.