Re: Problem Linking (win32)

Jim Carlock wrote:
Jim Carlock wrote:
:
[snip]
:
<file name="nasm32.inc">

%imacro .CODE 0
[section .text]
%endmacro

</file>
:
[snip]
:
: Not sure why the bracketed notation occurs, or why it ends up
: preferred, so if someone has a comment on that, that would be nice.

"Frank Kotler" wrote...
[somefunc dd real_address_of_somefunc]
: Since it isn't in *our* code, the linker must create it... or not.
: I've *only* seen this work using "-f obj" and Alink, but I think
: it's more a question of "which linker" than "which output format".
: Brian appears to be using it with GoLink, but there's some question
: if his code is "really" working right.

Still "some question" in my mind about when the brackets are necessary in Windows code. I, too, would welcome more comments on this!

:
: (Or did you mean the brackets around "[section .text]"? That's the
: "raw" form, which doesn't set the "__SECT__" standard macro. Possibly
: intentional, in this case - usually you want the "user" form "section
: .text", which does set "__SECT__".)

Thanks for the comments, Frank. "raw" form does not mean much to me at
the moment, maybe because I'm not looking at the NASM source code.

Okay... In "standard.mac", we see:

%define __SECT__ ; it ought to be defined, even if as nothing

%imacro section 1+.nolist
%define __SECT__ [section %1]
__SECT__
%endmacro
%imacro segment 1+.nolist
%define __SECT__ [segment %1]
__SECT__
%endmacro

%imacro absolute 1+.nolist
%define __SECT__ [absolute %1]
__SECT__
%endmacro

(Note that this is *not* the same as the "0-*" I posted! I'll have to RTFM on this and perhaps issue a correction.)

The way this is intended to be used is...

section my_specialstuff some_properties ; sets __SECT__
....
my_macro dah dah

If "my_macro" needs to switch sections, we can do:

%macro my_macro 2
[section .rdata] ; don't alter __SECT__
db %1
....
....
__SECT__
%endmacro

That way we can return to "whatever section we were in", no matter where the macro is invoked. I suspect that this was more useful in 16-bit segmented code, where multiple "far_code" and "far_data" segments were more common.

This code gets processed by a Perl script into C code, incidentally. Interesting concept...

[JC] How does one create a "%imacro .TEXT *" macro?

[FK] %imacro .TEXT 0-*

This is incorrect!

<http://mysite.verizon.net/fbkotler/nasmdoc4.html#section-4.3.3>

[FK] [section .text %1]
[FK] %endmacro
:
: The "-*" indicates a "greedy" parameter - everything after the zeroth
: (everything, IOW) is "lumped together" as "%1". I think that's what
: you have in mind. The "-" shouldn't be read as a minus sign, in this
: case - "%macro foo 1-3" means one through three parameters, not -1.
: "foo" with no, or more than 3, parameters won't match.
:

That's what I wanted to know. Thanks for the explanation. Maybe it's in
the documentation somewhere. There might be another word to describe that
character as well.

greedy, catchall, glob, asterisk, star

"Greedy" is what Nasm calls 'em.

: Personally, I find listing files almost completely useless. The
: "addresses" aren't runtime addresses but mere file offsets, half
: the "code" is left to be filled in by the linker (might be useful
: for debugging Nasm, but if I cared what the opcode was I'd do it
: "Wolfgang style"), and the "source code"... well, I *knew* that.
: What's to like?

Did you miss the other post where I indicated that I'm not seeing the
%define expansions (in the listing file (.lst)).

Right. Friendly Manual says:

-----------------
If you supply the -l option to NASM, followed (with the usual optional space) by a file name, NASM will generate a source-listing file for you, in which addresses and generated code are listed on the left, and the actual source code, with expansions of multi-line macros (except those which specifically request no expansion in source listings: see section 4.3.9) on the right. For example:

nasm -f elf myfile.asm -l myfile.lst
-----------------

Note "multi-line macros". So what you're seeing is "as documented". Dunno why. As I mentioned, I find the "-e" output more useful in figuring out what source code in "macroese" is really doing. (although I missed figuring out that "0-*" was wrong)

Is your Internet
connection ok?

No. Claimed the connection to news.verizon.net had timed out, when the message had actually been sent. Not the first time it has happened, but the connection *has* been erratic lately (stormy!), so it caught me...

Your post went through twice.

Yes. My apologies for the excessive bandwidth.

They looked the same and
I deleted the second post. Was that a mistake?

No.

I'm surprised Chuck let
it go through twice.

I think Chuck knows I *try* to stay on topic and doesn't check me much...

If what you're getting at here is a "support request" the Nasm presence of SourceForge includes a "tracker" for that:

<http://sourceforge.net/tracker/?group_id=6208&atid=356208>
(the "submit new" button)

I mentioned the developer's mailing list. The "archives" are "read only":

<http://sourceforge.net/mailarchive/forum.php?forum_name=nasm-devel>

If you want to participate, you can subscribe to the list:

<https://lists.sourceforge.net/lists/listinfo/nasm-devel>

I guess you can post to the list (or tracker) anonymously... have to monitor for any feedback via the (annoying) web interface...

One of the recent messages on the developer's list says, in part:

"I also saw a grumbling in c.l.a.x about not seeking community
involvement. It would be good if we could get users to participate in
this list, or at least nasm-users, rather than grumbling afterwards..."

My web site says, in part:

"If you have any interest, concern, contribution, or complaint regarding Nasm Development, please join our mailing-list."

The Main SF site says:

; Your Reports Aren't Going to /dev/null

"We're looking for your comments, suggestions and, of course, bug-reports. Report any suspicious behavior you encounter to help us improve the NASM for everyone!"

And:

"... and we are actively looking for more developers. In particular, we really need a maintainer for the MacOS X (Mach-O) backend!"

The Friendly Manual says:

"So here, for your coding pleasure, is NASM. At present it's still in prototype stage - we don't promise that it can outperform any of these assemblers. But please, please send us bug reports, fixes, helpful information, and anything else you can get your hands on (and thanks to the many people who've done this already! You all know who you are), and we'll improve it out of all recognition. Again."

Maybe we should be posting in all uppercase... :)

You, in particular, Jim, are in the "you know who you are" category! If you'd like to sign on as a "release technician" so you can update the "contributions" download package with your latest .chm yourself... I don't anticipate any objections from other developers... Or nudge me to keep it updated (you know the difference between "nudge" and "nag", I'm sure).

We've recently gained an active contributor - Victor van den Elzen - thanks Victor! Keith is having a go at the "macho64" issue. Chuck continues to be a big help. Still, H. Peter Anvin (of rPath Inc.), our chief maintainer, continues to do the bulk of the work - and he can't keep it up forever...

You can find daily (when changed) snapshots of Nasm at:

ftp://ftp.zytor.com/pub/nasm/snapshots

As you can see, development has "risen from the dead"! Updating frequently and letting us know of any "issues" will help prevent buggy releases! (the "test" directory is markedly improved, but a lot of bugs still show up in user projects) If you wanna watch the actual changes to the source:

http://repo.or.cz/w/nasm.git

It isn't as if Nasm's being controlled by a secret cabal. A shout of "thanks to the many people..." from some of the millions of satisfied Nasm users might boost team morale, and inspire 'em to bring us an even better Nasm. Never can tell until you try it!

(watch for 2.04 soon!)

Best,
Frank

.

Quantcast