nasm-users — Discussion and help for Nasm users.

[Nasm-users] Re: 1. NASM-Users sponsoring SPAM?? (John Rodriguez)

[<Ara...@Ar...>]

On Mon, 30 Jan 2006 20:31:43 -0800, you wrote:

>Today's Topics:
>
>   1. NASM-Users sponsoring SPAM?? (John Rodriguez)
>
>I received an email from one who calls herself Alisa Epps =3D
<snip>
Yea, Yea. =20
I sure everyone else on the list got it, also. =20
Did you have to quote the whole damn thing?
That means everyone got the whole thing, TWICE.

--=20
ararghmail601 (ararghmail601 at arargh dot com) http://www.arargh.com
BCET Basic Compiler Page: http://www.arargh.com/basic/index.html

[Nasm-users] NASM-Users sponsoring SPAM??

[John R. <jua...@am...>]

To Whom This May Concern:

I received an email from one who calls herself Alisa Epps =
(aba...@ch...). who is apparently using the NASM-Users group list =
for SPAM. I am enclosing the content of her email.

If you cannot restrict such usage, then please remove from your list.

John Rodriguez

# # #

Presidents Financial
Enters Online Poker Biz.
O.T.C Sym bol: P Z F C
Price: .

Getting Ready To Rumble?
Huge PR Campaign for Monday's Trading. You May Want To "Get In Early" =
Monday
Morning. Select Small Cap Sto cks Have Been Lining Savvy In vestors =
Pockets
With Juicy Prof its, As You May Know. You Gotta Time them Right, That's =
All.
Some of You May Have Scored on Other Poker Stocks Before.


Press Release Headlines(Go Read the Full Stories Now)

1)Presidents Financial Corporation Names Executive Team for Its =
SweetPrize
Inc. Subsidiary.


2)Presidents Financial Corporation Acquires Provider of Online Poker
Services -- SweetPrize Entertainment Inc.



Can You Make Some Fast Money on This One? Watch This One Trade Monday...





Information within this em  ail contains 4rward l0 0king statements =
within
the meaning of Section 27A of the Secu rities Act of nineteen thirty =
three and
Section 21B of the Securi ties Exch ange Act of nineteen thirty four. =
Any
statements that express or involve discussions with respect to predi =
ctions,
expec tations, beli efs, pla ns, projec tions, objec tives, goa ls, ass
umptions or future events or performance are not statements of =
historical fact and may
be 4rward 1o0king statements. Don't rely on them to make a decision. =
Please
be aware that the Company is not a reporting  comp any registered under =
the
Secur ities Exch ange Act of 19 34 and there is limited information =
available about the
comp any. As with many micr ocap st0c ks, today's  com pany has =
disclosable material
items you need to consider in order to make an informed and intelligent
in_vest ment decision. These items include: no rev enue in its most =
recent quarter, an
accumulated deficit since its inception, a negative net worth, reliance =
on loans from
offic ers and direct ors to pay expenses and a nominal ca sh position. =
It is a
devlopmental stage and not an operating Co mpany. The comp any is going =
to need fin ancing. If
that fina ncing does not occur, the comp any may not be able to continue =
as
a going concern in which case you could lose your entire in-ves tment. =
The
agreement announced above may not be definitive and may not occur. None =
of the material within this report shall be construed as any kind of =
inves tment advi ce or solicitat ion. Many of these compa nies are on =
the verge of bankruptcy. You  can lose all your m0ny by in-ves ting in =
this st0c k. In compliance with the Securities  Act of 1933, Sec tion =
17(b),The publi sher
of this newsle tter is contracted to receive twenty five tho usand do =
11ars
from a th ird party, not an offi cer, direc tor or affiliate shar-ehol =
der
for the circu lation of this rep ort. The party that pays us has a =
position
in the st ock they will sell at any time without notice. This could have =
a
negative impact on the price of the stoc k, causing you to lose mo ny. =
Their
intention is to sell now. All factual information in this report was =
gathered from public sources, including but not limited to Comp any Pre =
ss Releas es and Infor mation Stat ements.


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log =
files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D103432&bid=3D230486&dat=3D=
121642
_______________________________________________
Nasm-users mailing list
Nas...@li...
https://lists.sourceforge.net/lists/listinfo/nasm-users

# # # 

[Nasm-users] your stock update

[Alisa E. <aba...@ch...>]

Presidents Financial
Enters Online Poker Biz.
O.T.C Sym bol: P Z F C
Price: .

Getting Ready To Rumble?
Huge PR Campaign for Monday's Trading. You May Want To "Get In Early" Monday
Morning. Select Small Cap Sto cks Have Been Lining Savvy In vestors Pockets
With Juicy Prof its, As You May Know. You Gotta Time them Right, That's All.
Some of You May Have Scored on Other Poker Stocks Before.


Press Release Headlines(Go Read the Full Stories Now)

1)Presidents Financial Corporation Names Executive Team for Its SweetPrize
Inc. Subsidiary.


2)Presidents Financial Corporation Acquires Provider of Online Poker
Services -- SweetPrize Entertainment Inc.



Can You Make Some Fast Money on This One? Watch This One Trade Monday...





Information within this em  ail contains 4rward l0 0king statements within
the meaning of Section 27A of the Secu rities Act of nineteen thirty three and
Section 21B of the Securi ties Exch ange Act of nineteen thirty four. Any
statements that express or involve discussions with respect to predi ctions,
expec tations, beli efs, pla ns, projec tions, objec tives, goa ls, ass
umptions or future events or performance are not statements of historical fact and may
be 4rward 1o0king statements. Don't rely on them to make a decision. Please
be aware that the Company is not a reporting  comp any registered under the
Secur ities Exch ange Act of 19 34 and there is limited information available about the
comp any. As with many micr ocap st0c ks, today's  com pany has disclosable material
items you need to consider in order to make an informed and intelligent
in_vest ment decision. These items include: no rev enue in its most recent quarter, an
accumulated deficit since its inception, a negative net worth, reliance on loans from
offic ers and direct ors to pay expenses and a nominal ca sh position. It is a
devlopmental stage and not an operating Co mpany. The comp any is going to need fin ancing. If
that fina ncing does not occur, the comp any may not be able to continue as
a going concern in which case you could lose your entire in-ves tment. The
agreement announced above may not be definitive and may not occur. None of the material within this report shall be construed as any kind of inves tment advi ce or solicitat ion. Many of these compa nies are on the verge of bankruptcy. You  can lose all your m0ny by in-ves ting in this st0c k. In compliance with the Securities  Act of 1933, Sec tion 17(b),The publi sher
of this newsle tter is contracted to receive twenty five tho usand do 11ars
from a th ird party, not an offi cer, direc tor or affiliate shar-ehol der
for the circu lation of this rep ort. The party that pays us has a position
in the st ock they will sell at any time without notice. This could have a
negative impact on the price of the stoc k, causing you to lose mo ny. Their
intention is to sell now. All factual information in this report was gathered from public sources, including but not limited to Comp any Pre ss Releas es and Infor mation Stat ements.

Re: [Nasm-devel] Re: [Nasm-users] multisection example...

[H. P. A. <hp...@zy...>]

Frank Kotler wrote:
> Jacques Mony wrote:
> 
>> Hi,
>>
>>  Can anyone give me an example of how to use section.<secname>.start?
>>
>>  I tried this:
>>
>> ------ test.asm -------
>>
>> section mysection
>>
>> mysectionsize equ $ - section.mysection.start
>> --------------------------
>>
>> This will tell me section.mysection.start wasn't defined prior to its 
>> use...
>>
>> What's wrong?
> 
> 
> Dunno. I can confirm that it happens. I *think* you're doing everything 
> right. If I add the "-O" switch, the error message changes to "invalid 
> operand type". I suspect a bug. I'll pass this on to the developer's 
> list, and see if anyone has any ideas...
> 
> Thanks for testing the multisection support and letting us know!
> 

Okay, sorry for chiming in way, way late...

The reason it doesn't work is because section.mysection.start isn't seen 
by the assembler and linker as being in the same section as $.  Remember 
that outbin is really a linker.  In the case above, it's equivalent to 
$-$$, but the assembler doesn't know that, and if it had been a 
*different* section, it wouldn't have been able to resolve it.

	-hpa

Re: [Nasm-devel] Re: [Nasm-users] multisection example...

[Jacques M. <jac...@gm...>]

I'd like to retrieve a section size (in fact, multiple sections size)
from another section (which relocated the other sections). Is
section.<secname>.start supposed to be the solution? Should we,
instead, do this:

section mysection
mysectionsize: dd $ - section.mysection.start

And later user [mysectionsize] ? Will I be able to access it from
another section without some weird %define calculations?


On 11/13/05, anonymous coward <nas...@ya...> wrote:
> Frank,
> > > section mysection
> > > mysectionsize equ $ - section.mysection.start
> > >
> > > This will tell me section.mysection.start wasn't defined prior to its=
 use...
> > >
> > > What's wrong?
> >
> > Dunno. I can confirm that it happens. I *think* you're doing everything
> > right. If I add the "-O" switch, the error message changes to "invalid
> > operand type". I suspect a bug. I'll pass this on to the developer's
> > list, and see if anyone has any ideas...
>
> The section.<name>.start label is defined by bin_define_section_labels()
> in outbin.c. However, that function isn't called until after the second
> pass has been completed -- see line 1227.
>
> As a result, with the traditional two passes, EQU can't find the label
> during the first pass. And since EQU's operand is a critical expression
> you get the "symbol `<name>` not defined before use" error.
>
> With additional passes you get the "invalid operand type" warning; it
> happens to be the first of the two in parser.c, in line 690.
>
>
>
> __________________________________
> Yahoo! FareChase: Search multiple travel sites in one click.
> http://farechase.yahoo.com
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App Server. Downl=
oad
> it for free - -and be entered to win a 42" plasma tv or your very own
> Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
> _______________________________________________
> Nasm-users mailing list
> Nas...@li...
> https://lists.sourceforge.net/lists/listinfo/nasm-users
>


--
Jacques Mony
Programmeur-Analyste
Les services conseils Syst=E9matix inc.

Re: [Nasm-devel] Re: [Nasm-users] multisection example...

[anonymous c. <nas...@ya...>]

Frank,
> > section mysection
> > mysectionsize equ $ - section.mysection.start
> > 
> > This will tell me section.mysection.start wasn't defined prior to its use...
> > 
> > What's wrong?
> 
> Dunno. I can confirm that it happens. I *think* you're doing everything 
> right. If I add the "-O" switch, the error message changes to "invalid 
> operand type". I suspect a bug. I'll pass this on to the developer's 
> list, and see if anyone has any ideas...

The section.<name>.start label is defined by bin_define_section_labels()
in outbin.c. However, that function isn't called until after the second
pass has been completed -- see line 1227.

As a result, with the traditional two passes, EQU can't find the label
during the first pass. And since EQU's operand is a critical expression
you get the "symbol `<name>` not defined before use" error.

With additional passes you get the "invalid operand type" warning; it
happens to be the first of the two in parser.c, in line 690.


		
__________________________________ 
Yahoo! FareChase: Search multiple travel sites in one click.
http://farechase.yahoo.com

Re: [Nasm-users] multisection example...

[Frank K. <fbk...@co...>]

Jacques Mony wrote:
> Hi,
> 
>  Can anyone give me an example of how to use section.<secname>.start?
> 
>  I tried this:
> 
> ------ test.asm -------
> 
> section mysection
> 
> mysectionsize equ $ - section.mysection.start
> --------------------------
> 
> This will tell me section.mysection.start wasn't defined prior to its use...
> 
> What's wrong?

Dunno. I can confirm that it happens. I *think* you're doing everything 
right. If I add the "-O" switch, the error message changes to "invalid 
operand type". I suspect a bug. I'll pass this on to the developer's 
list, and see if anyone has any ideas...

Thanks for testing the multisection support and letting us know!

Best,
Frank

[Nasm-users] multisection example...

[Jacques M. <jac...@gm...>]

Hi,

 Can anyone give me an example of how to use section.<secname>.start?

 I tried this:

------ test.asm -------

section mysection

mysectionsize equ $ - section.mysection.start
--------------------------

This will tell me section.mysection.start wasn't defined prior to its use..=
.

What's wrong?

Thanks!

Jacques Mony (V2_OS project)

[Nasm-users] Code Is Acting Funny

[James W. <jam...@ya...>]

Hello! I am trying to improve my knowledge of NASM and
IA32 assembler by translating the lessons from
Petzold's Programming Windows into NASM assembler.

The thing is that adding additional instructions is
causing the program to draw erratically. BUT! That can
be fixed by adding nonsensical code.

For example, the program runs OK until I add the
following to it

push dword WHITE_BRUSH
call [GetStockObject]
; ignore result in eax

This is at a point where eax does not need to be
preserved.

Then I add the following code
push dword eax
add esp,4

The program runs properly now

As I check this code can be inserted after add esp,4

xor eax,eax

And it makes no difference. Because eax should not
matter there.

I realize that many people on this list are not using
Windows, but I am just stymied. Is there an issue with
code alignment, linking, what?

I must be doing something REALLY STUPID but I just
can't think where to look. I suppose that there is an
error somewhere else in my code but how could push eax
add esp,4 correct them?

Does it make sense to suspect the linker?

Thanks

James


		
____________________________________________________
Start your day with Yahoo! - make it your home page 
http://www.yahoo.com/r/hs 
 

[Nasm-users] Re: [Nasm-devel] Assembly Language Compiler

[<Ara...@Ar...>]

On Thu, 25 Aug 2005 20:12:25 -0700, you wrote:

<snip>
>   1. Re: Assembly Language Compiler (Frank Kotler)
>Message: 1
>Date: Thu, 25 Aug 2005 01:14:55 -0400
>From: Frank Kotler <fbk...@co...>
>Organization: N
>To: George G Fung <gu...@ju...>
>CC:  nas...@li...,  nas...@li...
>Subject: Re: [Nasm-devel] Assembly Language Compiler
>
>George G Fung wrote:
>> Hi Nasm,
>
>Hi George,
>
>This really isn't a "nasm-devel" question. The "nasm-users" list was=20
>created for this kind of question, so I'm cc'ing this reply there.
>
>> I have a bunch of subroutines and functions that are written in =
Assembly
>> Language and I would to compile them so that I can use them in my =
Visual
>> Basic programing . Is there a compiler available for doing this? I =
have
>> attached one of those Assembly Language subroutines for your viewing.
>
>What you've got there is 16-bit code for Masm. I'm not very familiar=20
>with VB, but I'm pretty sure it's 32-bits - so this code won't work, as=20
>written. I don't know how to use asm with VB, but I recall hearing that=20
>it can be done. I think the code you've got would require a *complete*=20
>rewrite to be used with Nasm and VB - maybe easier to start from=20
>scratch. Might be an interesting project - why don't we discuss it=20
>further on "nasm-users"?
>
<snip>
VB 1,2,3 were 16-bit.  VB 4 came in both flavors.  VB 5+ are 32-bit.

The short answer is: You can't.  Don't waste your time trying.

VB (thru 6 - the last that I have seen) has no ability to link with
static libs.  The only reasonable way to use ASM code of any kind in
VB is to put the ASM code in a DLL.


There is a (horribly convoluted) way around this limitation, but it
requires modifying the actual VB compile process.  That requires a
program that I think is no longer available from the original source.
In addition, you have to create an additional VB module with fake
versions of all the ASM routines that you want to use, in order for
there to be something to replace.  Then in the modified compile
process, you remove the VB fake module, and replace it with the ASM
obj file.  Roaring Pain.  Better to make a DLL.

The only useful thing that I use the compile modify routine for is to
turn on the pass 2 compiler asm listing.  You can't actually compile
the output, but it quickly shows how badly bloated some parts of VB
generated code really is.


--=20
ararghmail508 (ararghmail508 at arargh dot com) http://www.arargh.com
BCET Basic Compiler Page: http://www.arargh.com/basic/index.html

[Nasm-users] Re: [Nasm-devel] Assembly Language Compiler

[Frank K. <fbk...@co...>]

George G Fung wrote:
> Hi Nasm,

Hi George,

This really isn't a "nasm-devel" question. The "nasm-users" list was 
created for this kind of question, so I'm cc'ing this reply there.

> I have a bunch of subroutines and functions that are written in Assembly
> Language and I would to compile them so that I can use them in my Visual
> Basic programing . Is there a compiler available for doing this? I have
> attached one of those Assembly Language subroutines for your viewing.

What you've got there is 16-bit code for Masm. I'm not very familiar 
with VB, but I'm pretty sure it's 32-bits - so this code won't work, as 
written. I don't know how to use asm with VB, but I recall hearing that 
it can be done. I think the code you've got would require a *complete* 
rewrite to be used with Nasm and VB - maybe easier to start from 
scratch. Might be an interesting project - why don't we discuss it 
further on "nasm-users"?

Best,
Frank

Re: [Nasm-users] Section cannot be switch to writeable :(

[Frank K. <fbk...@co...>]

Frank Kotler wrote:

> Call it "kode", or something...

I should probably have mentioned that you'll have to specify "exec" as 
well as "write"!

section kode write exec

or so.

Best,
Frank

Re: [Nasm-users] Section cannot be switch to writeable :(

[Frank K. <fbk...@co...>]

Judecca wrote:
> Hi!
> I've gopt a problem with the nasm assembler.
> I am coding a small app that needs to write in the .text section (to modify some
> opcodes directly).
> Then i declared my section as follow :
> section .text write
> 
> However when i try to write in the code, i got a segfault! (i precise that i'm
> compiling and running it under linux and i'm using the last version of nasm of
> sourceforge)
> 
> What shall I do to make this section writeable ?

Call it something besides ".text".

Your problem is not strictly with Nasm, but the fact that ld "knows" the 
name ".text", and changes it to readonly, even if you said "write". This 
can be verified by doing "objdump -h myfile.o" and "objdump -h myfile". 
Nasm give you the flags you asked for in the .o file, but ld changes it.

Call it "kode", or something...

Best,
Frank

[Nasm-users] Section cannot be switch to writeable :(

[Judecca <dar...@ya...>]

Hi!
I've gopt a problem with the nasm assembler.
I am coding a small app that needs to write in the .text section (to modify some
opcodes directly).
Then i declared my section as follow :
section .text write

However when i try to write in the code, i got a segfault! (i precise that i'm
compiling and running it under linux and i'm using the last version of nasm of
sourceforge)

What shall I do to make this section writeable ?

Re: [Nasm-users] Linux "hello world" segfault on 2.6.11

[Frank K. <fbk...@co...>]

Frank Kotler wrote:

> That appears to be "expected" behavior with 2.6.11+.

I'm not sure which version this started with, actually - lets say
"recent kernels".

>> I wonder
>> why I don't need to do this with the gnu asssembler.
> 
> Good question. Don't you? The code you cited:
> 
> http://www.tldp.org/HOWTO/Assembly-HOWTO/hello.html
> 
> ... indicates an explicit ".data" section for both the Nasm and (G)as 
> versions. If a (G)as version works without a ".data" section... perhaps 
> Gas makes a writable section at the end, whether you ask for one or not. 
> I haven't tried it. Only thing I can think of.

That seems to be the case. IOW, "return 42" *does* work okay when
assembled with Gas (the examples in Jonathan's book, e.g.).

.globl _start

.text
_start:
movl $1, %eax
movl $42, %ebx
int $0x80

Linked with ld, doesn't segfault. "objdump -h" says:

hwg.o:     file format elf32-i386

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
   0 .text         0000000c  00000000  00000000  00000034  2**2
                   CONTENTS, ALLOC, LOAD, READONLY, CODE
   1 .data         00000000  00000000  00000000  00000040  2**2
                   CONTENTS, ALLOC, LOAD, DATA
   2 .bss          00000000  00000000  00000000  00000040  2**2
                   ALLOC

OTOH, the "same code" in Nasm...

global _start

section .text

_start:
mov eax, 1
mov ebx, 42
int 80h

*Does* segfault! objdump says:

hw7.o:     file format elf32-i386

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
   0 .text         0000000c  00000000  00000000  00000130  2**4
                   CONTENTS, ALLOC, LOAD, READONLY, CODE
   1 .comment      0000001f  00000000  00000000  00000140  2**0
                   CONTENTS, READONLY

> The 2.6 code appears to 
> *require* that your executable have a writeable section, and that it be 
> at the end (ld apparently takes care of the latter, if we use it).
> 
> Curiously, marking the code section writeable seems to solve the problem 
> using Fasm, but *not* using Nasm. This *may* indicate a bug in what 
> Nasm's doing with "section .text write" - needs further research...

Or it could be ld's doing...

global _start

section .text write
  msg db 'hello world', 10
  msg_len equ $ - msg

_start:
     mov eax, 4
     mov ebx, 1
     mov ecx, msg
     mov edx, msg_len
     int 80h

     mov eax, 1
     xor ebx, ebx
     int 80h

Linked with ld, segfaults. "objdump -h hw8.o" (Nasm's output):

hw8.o:     file format elf32-i386

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
   0 .text         0000002b  00000000  00000000  00000160  2**4
                   CONTENTS, ALLOC, LOAD, RELOC, CODE
   1 .comment      0000001f  00000000  00000000  00000190  2**0
                   CONTENTS, READONLY

Note that our .text section is not marked READONLY. But after linking:

hw8:     file format elf32-i386

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
   0 .text         0000002b  08048080  08048080  00000080  2**4
                   CONTENTS, ALLOC, LOAD, READONLY, CODE
   1 .bss          00000000  080490ac  080490ac  000000ab  2**0

   2 .comment      0000001f  00000000  00000000  000000ab  2**0
                   CONTENTS, READONLY

So it looks like ld is doing us dirt - or perhaps Nasm's not "telling it
right". Funny, objdump "gets it" okay...

Still haven't looked at the "elf.inc" macros in asmutils...

Later,
Frank

Re: [Nasm-users] Linux "hello world" segfault

[Frank K. <fbk...@co...>]

John Daniels wrote:
> Frank,
> 
> If I throw in a bss or data section at the beginning
> or end of the file, it no longer segfaults.

That appears to be "expected" behavior with 2.6.11+. Whether it's 
"intended" behavior is still under discussion...

> I wonder
> why I don't need to do this with the gnu asssembler.

Good question. Don't you? The code you cited:

http://www.tldp.org/HOWTO/Assembly-HOWTO/hello.html

... indicates an explicit ".data" section for both the Nasm and (G)as 
versions. If a (G)as version works without a ".data" section... perhaps 
Gas makes a writable section at the end, whether you ask for one or not. 
I haven't tried it. Only thing I can think of. The 2.6 code appears to 
*require* that your executable have a writeable section, and that it be 
at the end (ld apparently takes care of the latter, if we use it).

Curiously, marking the code section writeable seems to solve the problem 
using Fasm, but *not* using Nasm. This *may* indicate a bug in what 
Nasm's doing with "section .text write" - needs further research...

Best,
Frank

Re: [Nasm-users] Linux "hello world" segfault

[Frank K. <fbk...@co...>]

John Daniels wrote:
> I am trying to get TLDP's "Hello World" program to
> compile
> (http://www.tldp.org/HOWTO/Assembly-HOWTO/hello.html).
> I followed the instructions to build it: 
>  
> $ nasm -f elf hello.asm 
> $ ld -s -o hello hello.o 
>  
> When I try to run the program with "./hello", I get a
> segmentation fault. Does anybody know what the problem
> could be? I tried the gas example following the
> instructions in the howto, and it seemed to work.
> Could somebody tell me what I'm doing wrong? I'm using
> nasm 0.98.39 with ld 2.16. I'm running a 2.6.11
> kernel.

John Daniels wrote:

 >I am trying to get TLDP's "Hello World" program to
 >compile
 >(http://www.tldp.org/HOWTO/Assembly-HOWTO/hello.html).
 >I followed the instructions to build it:
 >
 >$ nasm -f elf hello.asm
 >$ ld -s -o hello hello.o
 >
 >When I try to run the program with "./hello", I get a
 >segmentation fault. Does anybody know what the problem
 >could be? I tried the gas example following the
 >instructions in the howto, and it seemed to work.
 >Could somebody tell me what I'm doing wrong? I'm using
 >nasm 0.98.39 with ld 2.16. I'm running a 2.6.11
 >kernel.
 >
Hi John,

I was going to ask, on the forum (I assume that's you), what kernel you 
were running. 2.6.11 (or so) seems to have quietly introduced a "new 
requirement" beyond the existing ELF spec. The last section in your 
binary must be writable!

This means that "tricks" like putting your constant "hello world" data 
in the code section (to save a section and shorten the executable), is 
no longer going to work!

The "elfexe" example that ships with Fasm segfaults on this kernel, too. 
(moving the data section after the code fixes it)

It's a bit of a puzzle why the code you cite has a problem, since it 
*looks* perfectly okay. I think I tested something "almost exactly" the 
same, and it worked. Try moving the ".data" section to the end, or 
adding a ".bss" section whether you need one or not...

Something that will screw us up, that we might have gotten away with 
before, is misspelling section names. Nasm "knows" the names ".text", 
".data", ".rodata", and ".bss". "User defined" names get the same 
properties as ".text", by default. So if we type "section data" - 
leaving out the dot - we get a "nowrite" section, which will segfault on 
this kernel. Newsreader software is prone to messing with dots... the 
Nasm forum is known to eliminate "extra" spaces for us, turning "section 
.data" into "section.data" - which is *not* the same thing to Nasm! 
Possible that something like this happened to your code?

The reason why this is happening isn't an accident. The elf loader in 
previous kernels wasn't checking return values from some functions that 
*could* have been failing to zero memory - a breach of security. So it's 
a Good Thing the changes were made, but it puts us in the position that 
"valid" (according to elf spec) binaries won't run. I really think it 
would be a better kernel if it would issue a diagnostic and exit 
("scream and die") instead of just sending SIG_SEGV... To that extent, 
it's a "bug", IMHO. But we can find workarounds, I think - just make 
sure you've got a ".data" or ".bss" section (I think ld should put them 
after ".text", regardless of where they appear in the source). I don't 
know where this leaves you with your code - since you do that. All I can 
suggest is "make sure '.data' is spelled wright".

More info on this in news:alt.lang.asm under the odd subject "Blueflops 
ate my X"... I'll try to post more on the subject if/when I get a better 
grip on it. Since the kernel's been released (and 2.6.12 is the same), 
about all we can do is "get the word out"... Strictly speaking, it's not 
a "Nasm problem". (Good! :)

Best,
Frank

[Nasm-users] Linux "hello world" segfault

[John D. <joh...@ya...>]

I am trying to get TLDP's "Hello World" program to
compile
(http://www.tldp.org/HOWTO/Assembly-HOWTO/hello.html).
I followed the instructions to build it: 
 
$ nasm -f elf hello.asm 
$ ld -s -o hello hello.o 
 
When I try to run the program with "./hello", I get a
segmentation fault. Does anybody know what the problem
could be? I tried the gas example following the
instructions in the howto, and it seemed to work.
Could somebody tell me what I'm doing wrong? I'm using
nasm 0.98.39 with ld 2.16. I'm running a 2.6.11
kernel.
 
Thanks.

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

[Nasm-users] Re: [linux-nasm-users] Assembler bugs

[Frank K. <fbk...@co...>]

jeff wrote:
> 
> Hello all,

Hiya Jeff,

> My list of things to avoid in nasm now has
> two items.  I've wasted a few days tracking
> these down, so hopefully this will save everyone
> else some time:

Thanks for the feedback! Since much of this isn't limited to
Linux, I'll cc this to a couple other lists, if you don't
mind. (if you do mind - too late, sorry :)

> 
>  1.  Any line ending with "\" will convert the
>      next line into a commennt.

This is not correct, AFAIK. Ending a line with a backslash
causes Nasm to append the following line to the line ending
in a backslash, as if it were written all on one line.

>      This becomes a
>      serious problem if the "\" is at the end
>      of a comment and the next line is a assembler
>      instruction.

It "continues" the line. If you don't intend to "continue"
the comment, don't end the line in a backslash!

>      No warning is given and the
>      instruction is ignored.  The problem here is
>      knowing that the problem happened.  The GDB
>      debugger often shows source and everything looks
>      ok.

I'll have to look into that. My "quickie" test is puzzling
me - ";this is a comment\" is *not* being continued, and the
following line *is* being assembled. This is not the
intended behavior - it's the way *I'd* like to see it work,
but the "team" want's it to work like gcc, which apparently
*does* continue the comment. 

Ah! I, see! I was apparently using a "modified" version...
an attempt to "fix" the behavior you don't like :) Using
straight 0.98.39, it *does* continue the comment to the next
line. Okay... In gdb, a "listing" of the file shows what we
wrote, a "disassembly" (or stepping through the program)
shows the next line *not* assembled. This is potentially
confusing, I guess, but I think it's "correct"... How would
you like to see it work?

I can send you my "fix", but it's logically incorrect - "mov
al, ';'\" will treat the ';' as if it were a comment
character, and *not continue the line (not that there's any
logical reason to continue this particular line...) Well,
it's short, here it is:

--- /home/fbk/nasm/preproc.c	Mon Jan 17 00:24:02 2005
+++ /home/fbk/nasmtemp/preproc.c	Wed Feb  2 20:07:30 2005
@@ -663,14 +663,16 @@
         if (p > buffer && p[-1] == '\n') {
             /* Convert backslash-CRLF line continuation
sequences into
                nothing at all (for DOS and Windows) */
-            if (((p - 2) > buffer) && (p[-3] == '\\') &&
(p[-2] == '\r')) {
+            if (((p - 2) > buffer) && (p[-3] == '\\') &&
(p[-2] == '\r')
+                && 0 == strchr(q, ':')) {
                 p -= 3;
                 *p = 0;
                 continued_count++;
             }
             /* Also convert backslash-LF line continuation
sequences into
                nothing at all (for Unix) */
-            else if (((p - 1) > buffer) && (p[-2] == '\\'))
{
+            else if (((p - 1) > buffer) && (p[-2] == '\\')
+                     && 0 == strchr(q, ';')) {
                 p -= 2;
                 *p = 0;
                 continued_count++;


I *strongly* suggest that you *don't* use this code! It's
too simple-minded to work correctly! (but it *did* work on
my "quickie test")

>      Another aspect of this problem is that editors
>      with assembler syntax higlighting show the
>      comment line as an istruction.  This adds a
>      confusing twist.

This is a problem for authors of syntax-highlighting editors
to solve. Yes, it's "new syntax" for Nasm, and it *does*
break some existing code - which we *try* to avoid - but it
was a much-requested, and badly-needed (IMO) feature.

>  2.  The warning "ld can not find entry symbol" may
>      be triggered by adding the -O2 flag to nasm.

It does a lot worse than that! It emits totally bogus code.
This is a bug in Nasm - you *should* get a "phase error" (or
"not enough passes") message and quit. This'll be fixed for
0.98.40, probably.

>      Once again this problem is easy to fix, just
>      change the -O flag to -O1 or omit it.

Well, you could do that... but the better solution would be
to use a *larger* parameter to the "-O" switch - I use
"-O999", when I use the "-O" switch at all.

>      The problem
>      is that you can be working away and the problem
>      pops up.  What caused it?

A change in the way the parameter to the "-O" switch is
processed. In the original optimizer code, "-O2" and "-O3"
were special-cased to give you 10 and 15 (maximum) extra
"optimizing" passes. "-O4" gave you only 4 passes... The
Nasm development team, in its infinite wisdom, decided that
this inconsistancy, and the special-casing of "-O2" and
"-O3", should be removed in favor of "the number you give is
the number you get" ("-O1" is still "special"). If this
produced the proper error-message in the case of too few
passes, it wouldn't be too bad.

Personally, I don't see any reason to limit the maximum
number of passes at all - it isn't faster, Nasm quits when
it's done. I'd give 999 passes - or 999999 (some code can
take a lot of passes to resolve!) - if any number >=2 was
given. In the case of code that simply *won't* resolve, this
would make Nasm appear to hang... or you'd wait a *long*
time for an error message. Since it doesn't work that way,
we just have to use a good big number.

I haven't looked at your latest code, Jeff, but with an
earlier version, I thought I saw something weird... the
executable was bigger with "-O999" than with no "-O" switch.
(IIRC, I had to add a couple "near" specifiers to get it to
assemble without at least "-O1"). I've gotta re-check, and
see if that was really happening. This would be *very*
puzzling, if true, but it's a different issue than the lack
of an error - and incorrect code - if "-O2" isn't enough (I
think...).

> Both of these problems were found by going back to nasm
> version 22 which has been rock solid here.

Suit yourself. It has come to my attention that the latest
"asmutils" insists on "pure" 0.98 - I haven't been able to
find out why - perhaps to avoid 0.98.37, which had broken
elf output. Code is available clear back to 0.91, for those
who don't like "new fangled gadgets". But there's a *reason*
for all those releases - a number of serious bugs have been
found and fixed! If you're assembling code that doesn't
trigger these bugs, you don't need to upgrade, but I assure
you, they're there waitin' for ya!

Best,
Frank

[Nasm-users] Re: [Nasm-devel] 2 Problems: (Strange Linking Problem) && (Strange Syntatx Error)

[H. P. A. <hp...@zy...>]

H. Peter Anvin wrote:
> anonymous coward wrote:
> 
>>> 1: *Strage Linking Problem*
>>
>> I'm not a Linux/GCC expert. But in the first case
>> your code becomes start(), whereas in the second
> 
> 
> _start() actually; ELF doesn't use an extra underscore.
> 

N.B. For those that may not be familiar: some ABIs use a convention to 
preface C-language identifiers with underscores (_), in order to make 
identifiers generated by the compiler invisible to C.  That would, 
however, make the dlsym() function awkward to use; instead ELF leaves C 
identifiers as-is, and identifiers that are supposed to be invisible to 
C instead contain a dot (.) somewhere.

It is, however, common on ELF systems for FORTRAN symbols to be lower 
case and contain a *trailing* underscore, for example the FORTRAN 
subroutine "BLUTTAN" would become "bluttan_" on a typical ELF system, 
and would frequently be callable from C as bluttan_().

	-hpa

[Nasm-users] Re: [Nasm-devel] 2 Problems: (Strange Linking Problem) && (Strange Syntatx Error)

[H. P. A. <hp...@zy...>]

anonymous coward wrote:
>>1: *Strage Linking Problem*
> 
> 
> I'm not a Linux/GCC expert. But in the first case
> your code becomes start(), whereas in the second

_start() actually; ELF doesn't use an extra underscore.

> case it becomes main(). So have you looked at what
> start() does in the second case? (Try objdump.)

_start is the first thing that gets called, and is usually the 
entrypoint to the C library, which then calls main.  When you link with 
gcc you link in the C library initialization code.

	-hpa

Re: [Nasm-users] 2 Problems: (Strange Linking Problem) && (Strange Syntatx Error)

[Frank K. <fbk...@co...>]

Matthias-Christian Ott wrote:
> 
> Hi!
> I've 2 Problems with nasm:
> 
> 1: *Strage Linking Problem*
> 
> I have this code:
> 
> SECTION .DATA
>         hello:     db 'Hello world!',10
>         helloLen:  equ $-hello
> 
> SECTION .TEXT
>         GLOBAL main
> 
> main:
>         ; Write 'Hello world!' to the screen
>         mov eax,4            ; 'write' system call
>         mov ebx,1            ; file descriptor 1 = screen
>         mov ecx,hello        ; string to write
>         mov edx,helloLen     ; length of string to write
>         int 80h              ; call the kernel
> 
>         ; Terminate program
>         mov eax,1            ; 'exit' system call
>         mov ebx,0            ; exit with error code 0
>         int 80h              ; call the kernel
> 
> If try to assemble, link (by using ld) and run it, I only get a
> segementation fault (I have to rename main to _start):

"_start" is the default entrypoint known to ld (should be
declared "global" so ld can "see" it). You can tell ld to
use a different symbol (or an address, I guess) as the
entrypoint with "--entry=main".

> nasm -f elf hello.asm
> ld -s -o hello hello.o

I'm surprised you don't get a complaint from ld here!

> ./hello
> segementation fault
> 
> If I try to link it with the gcc (_start -> main), everything works fine.

C knows "main" as the entry into *your* part of the code,
and it's "call"ed, so you can end with "ret". In this case
the "_start" label occurs in the "C startup code", which
diddles the stack, among other things, and then calls
"main".

> What's wrong? Why doesn't it work?

Just that you didn't use "_start" or tell ld another
entrypoint.

> 2: *Strange Syntax Error*
> 
> I have this code (I know that it will only work in the priviledged mode,
> but it should assemble cleanly (?)):
> 
> global sys_core_in
> 
> sys_core_in:
>         push    ebp
>         push    dx

This will work, but you probably want to push/pop edx here.
It'll generate shorter code, and leave your stack aligned
better.

>         mov     ebp,esp
>         in      edx,[ebp+4]

<http://nasm.sourceforge.net/doc/html/nasmdocb.html#section-B.4.119>

>         mov     eax,dx

I don't think you'll need to do this, but...

<http://nasm.sourceforge.net/doc/html/nasmdocb.html#section-B.4.156>

... or use "movzx"... but I don't think you need it...

>         pop     dx
>         pop     ebp
>         ret
> 
> global sys_core_out
> 
> sys_core_out:
>         push    ebp
>         mov     ebp,esp
>         out     [ebp+4],[ebp+8]

<http://nasm.sourceforge.net/doc/html/nasmdocb.html#section-B.4.194>

>         pop     ebp
>         ret
> 
> If I try to assemble it I get this:
> 
> io.s:7: error: invalid combination of opcode and operands
> io.s:8: error: invalid combination of opcode and operands
> io.s:18: error: invalid combination of opcode and operands
> 
> What's wrong with the syntax?

Just like what the error message says - the operands you're
using aren't valid for the opcodes.

I don't know anything about "privileged mode", but you can
get "permission" to in/out ports with "sys_ioperm"... might
be useful for testing(?).

Best,
Frank

P.S. I've removed "nasm-devel" from the reply... not really
a "development issue"...

[Nasm-users] Re: [Nasm-devel] 2 Problems: (Strange Linking Problem) && (Strange Syntatx Error)

[anonymous c. <nas...@ya...>]

> 1: *Strage Linking Problem*

I'm not a Linux/GCC expert. But in the first case
your code becomes start(), whereas in the second
case it becomes main(). So have you looked at what
start() does in the second case? (Try objdump.)

> 2: *Strange Syntax Error*
>         [...]
>         in      edx,[ebp+4]
>         mov     eax,dx
>         [...]
>         out     [ebp+4],[ebp+8]
> 
> If I try to assemble it I get this:
> 
> io.s:7: error: invalid combination of opcode and operands

Correct. The IN operands are restricted/fixed.
Take a look at Intel/AMD's reference manuals.

> io.s:8: error: invalid combination of opcode and operands

Correct. The operands either need to be of the
same size, or you need to use MOVSX or MOVZX.

> io.s:18: error: invalid combination of opcode and operands

Correct. The OUT operands are restricted/fixed.
Take a look at Intel/AMD's reference manuals.


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

[Nasm-users] 2 Problems: (Strange Linking Problem) && (Strange Syntatx Error)

[Matthias-Christian O. <mat...@ti...>]

Hi!
I've 2 Problems with nasm:

1: *Strage Linking Problem*

I have this code:

SECTION .DATA
        hello:     db 'Hello world!',10
        helloLen:  equ $-hello

SECTION .TEXT
        GLOBAL main

main:
        ; Write 'Hello world!' to the screen
        mov eax,4            ; 'write' system call
        mov ebx,1            ; file descriptor 1 = screen
        mov ecx,hello        ; string to write
        mov edx,helloLen     ; length of string to write
        int 80h              ; call the kernel

        ; Terminate program
        mov eax,1            ; 'exit' system call
        mov ebx,0            ; exit with error code 0
        int 80h              ; call the kernel

If try to assemble, link (by using ld) and run it, I only get a 
segementation fault (I have to rename main to _start):

nasm -f elf hello.asm
ld -s -o hello hello.o
./hello
segementation fault

If I try to link it with the gcc (_start -> main), everything works fine.

What's wrong? Why doesn't it work?

2: *Strange Syntax Error*

I have this code (I know that it will only work in the priviledged mode, 
but it should assemble cleanly (?)):

global sys_core_in

sys_core_in:
        push    ebp
        push    dx
        mov     ebp,esp
        in      edx,[ebp+4]
        mov     eax,dx
        pop     dx
        pop     ebp
        ret

global sys_core_out

sys_core_out:
        push    ebp
        mov     ebp,esp
        out     [ebp+4],[ebp+8]
        pop     ebp
        ret

If I try to assemble it I get this:

io.s:7: error: invalid combination of opcode and operands
io.s:8: error: invalid combination of opcode and operands
io.s:18: error: invalid combination of opcode and operands

What's wrong with the syntax?

Thanks
Matthias-Chritian Ott

[Nasm-users] Re: Sorta announce - Nasm 0.98.39 sorta available

[Frank K. <fbk...@co...>]

Now available at SourceForge:

http://www.sf.net/projects/nasm

Please upgrade!


Frank Kotler wrote:
> 
> Nasm 0.98.39 is available - but not on SourceForge quite
> yet... they're having some "transitional difficulties" at
> the moment. We'll get copies up there as soon as the release
> system seems stable - couple days, probably.
> 
> Meanwhile:
> 
> http://www.kernel.org/pub/software/devel/nasm/
> 
> The "binaries" are not complete, but win32, djgpp, and Linux
> are available, plus, of course, a source package. 0.98.39
> goes from C89 to C99, which apparently is causing some build
> problems with some compilers. If you need/want to build Nasm
> from source, and you can't figure it out, holler for help.
> If you *can* figure it out, *post* some help, please.
> 
> For djgpp, you need the "beta 2.04" version, for example
> (Thanks to Bart Oldeman for that tip). The Makefile created
> by "configure" in Linux (and rdoff/Makefile) needs "std=c99"
> removed. (Mkfiles/Makefile.unx seems okay) I hope we'll have
> a "cleanup release" out sooner than the year and a half that
> this release took, but no promises.
> 
> I *really* hope that everyone will upgrade to 0.98.39 as
> soon as possible! Why? Well... a "Serious Problem" has been
> uncovered in Nasm - all versions prior to 0.98.39 (maybe not
> *really* early versions). We all know enough  not to run
> code from untrusted sources (I hope!). Turns out you're
> vulnerable even *assembling* malicious source with Nasm.
> Yes, a <line-noise> buffer overflow (potentially
> exploitable). Betov gets "I told you so" rights. Not
> actually *caused* by using C, but C provided the hole for us
> to fall into. I am deeply embarrassed that this remained
> undiscovered so long!
> 
> The vulnerability was discovered by Jonathan Rockway (a
> student - since Nasm was written by a student, this is
> perhaps appropriate), reported to us by D.J.Bernstein (his
> instructor). Fixed by Ed Beroset. Thanks to all involved!
> 
> Other than that, the changes aren't too exciting. Nice new
> rdoff stuff from Yuri Zaporogets, for the few who use rdoff.
> Otherwise minor cleanups not worth mentioning...
> 
> Please upgrade and get rid of that buffer overflow! If you
> can't/won't upgrade, please *examine* any source code from
> less-than-fully-trusted sources for anything that looks
> "weird". AFAIK, no one is targetting Nasm, but... we don't
> need this crap!
> 
> Best,
> Frank
> 
> ----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
> http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
> ----= East and West-Coast Server Farms - Total Privacy via Encryption =----