Seg fault with hla 1.99 on Fedora 8 linux

On Mar 1, 12:43_am, nbaker2328 <spamt...@crayne.org> wrote:
>
> _ _ _ _ lea eax, [initVal] ; or use 'mov eax, initVal'
> _ _ _ _ push eax

Or just 'push initVal'  ...talking about detours... :)

> _ _ _ _ call printf
> _ _ _ _ add esp, 4
>
> _ _ _ _ movsx eax, BYTE [i8] ; sign-extended mov
> _ _ _ _ push eax
> _ _ _ _ lea eax, [str8]
> _ _ _ _ push eax
> _ _ _ _ call printf
> _ _ _ _ add esp, 8

Or ( for more clarity ) something like...

sub esp, 8
mov al, BYTE [i8]
movsx [esp+8], al
mov [esp+4], str8
call printf
add esp, 8

Nathan.

On Mar 1, 5:29 am, nbaker2328 <spamt...@crayne.org> wrote:
>
> sub esp, 8
> mov al, BYTE [i8]
> movsx [esp+8], al
> mov [esp+4], str8
> call printf
> add esp, 8
>

To correct that:

sub esp, 8
movsx eax, BYTE [i8]
mov ebx, str8
mov [esp+4], eax
mov [esp], ebx
call printf
add esp, 8

Nathan.

nbaker2328 wrote:
> On Feb 29, 3:52 am, Frank Kotler  <spamt...@crayne.org> wrote:
> 
>
>
> One should not use Nasm to learn assembly!  :)

Perhaps. When using Nasm, the segfaults are *my* fault. This might tend
to demoralize the beginner...
 
>
>
> Your code assumes that "AoA student" knows what "inc, call, jnz, xor,
> and etc."

Yes. My mistake - I should have left that until after they've learned
assembly language... :)

My "Clueless Newbie's Guide to Hello World in Nasm" once had a "chapter
two", in which every "mov", etc. was a link to the instruction in the
Nasm manual, and every "int" was a link to RBIL. Then Nasm and RBIL both
updated, breaking all my links...

> is this early in the book.  A few chapters in, it covers
> some basic instructions.

Yeah... I did not select the example. In "my book" (which I am *far* to
lazy to ever write), this would be "example13" or so.

> My conversion of it suffers the same
> problem.

It's a paradox. You can *tell* 'em about "mov", but if you want to
*show* 'em "mov", you need a lot more than "mov" to have anything to show!

> Guess it'd be best to stuff some macros away into an include
> file...

%include "you_are_not_expected_to_understand_this.inc"

Yeah, that's one common approach. It may be the best one, but it kind of
grates on me. I'd start with:

global _start

section .text
_start:

mov bl, 42
mov eax, 1
int 80h

and work up from there (Jonathan Bartlett's PGU, for example). But AoA
is aimed at a "course" which lasts some number of ws that will fit in
4 bits. This changes the picture! In particular, if the course is
supposed to be "Computer Architecture and Assembly Language", you might
like to be able to write an assembly language program that explored some
computer architecture... This is where "the_hard_parts.inc" comes in.
"the_OS_specific_parts.inc" has value on its own, of course.

Some very minor nits...

> 	lea eax, [initVal] ; or use 'mov eax, initVal'

Might want to leave "lea" until we need it. "tell me the address of the
object whose address is initVal" always seems like overkill to me...

> 	push eax

push initVal ?

> 	call printf
> 	add esp, 4

I guess "add" isn't too mysterious to spring on the unsuspecting newbie. :)

> 	movsx eax, BYTE [i8] ; sign-extended mov

I was hoping we could ignore "sign" for now. :) "sub" kinda requires it,
I guess. In practice, I rarely find the need to display a negative number...

>     ; Compute the absolute value of the

Not really...

> 	add LONG [i32], 32323200

Nasm likes "LONG"? So it does! We live and learn. I'd have used "dword"...

Nits aside, nice example. I guess to "port" it to Windows, we'd want to
add "--prefix _" to nasm's command line. Paul Carter's examples use a
"-d ELF_TYPE" on the command line to remove underscores for ELF... And
he "hides" the use of printf (etc.). His "first.asm" inputs two numbers
from the user, adds them, and prints the result. I simplified this to be
like "HelloWorldWithVar", just to see what it would look like using this
approach...

Best,
Frank

; file: hwint.asm
; This program prints a message and a number.
;
; Cribbed from Dr. Paul Carter's "first.asm", mostly
; http://www.drpaulcarter.com/pcasm
;
; To create executable:
;
; These assume that asm_io.o has been built. If not:
; nasm -f <your output format> -d <YOUR_TYPE> asm_io.asm
;
; Using djgpp:
; nasm -f coff -d COFF_TYPE hwint.asm
; gcc -o hwint hwint.o driver.c asm_io.o
;
; Using Borland C/C++
; nasm -f obj -d OBJ_TYPE hwint.asm
; bcc32 hwint.obj driver.c asm_io.obj
;
; Using Linux: (only one I've tested)
; nasm -f elf -d ELF_TYPE hwint.asm
; gcc -o hwint hwint.o driver.c asm_io.o
;
; Mac? Why not?
; nasm -f macho - d ELF_TYPE(??? no underscores?) hwint.asm
; gcc(???) -o hwint hwint.o driver.c asm_io.o
;

;
; this provides the requisite "extern" declarations,
; and some (neat!) macros that we don't use here
;
%include "asm_io.inc"

;
; initialized data is put in the .data segment
;
segment .data
;
; These labels refer to strings used for output
;

message db "Hello, World of assembly language (and C)", 10, 0
answer db "InitDemo's value is ", 0

;
; An integer variable.
;

InitDemo dd 5

;
; code is put in the .text segment
;
segment .text
global  asm_main  ; make ourselves known to the linker
asm_main:
enter   0,0               ; setup routine
pusha

mov     eax, message      ; print out prompt
call    print_string

mov	eax, answer
call	print_string

mov     eax, [InitDemo]
call    print_int         ; print out InitDemo

call    print_nl          ; print new-line

popa
mov     eax, 0            ; return back to C
leave
ret

On Mar 1, 3:36 pm, Frank Kotler  <spamt...@crayne.org> wrote:
> nbaker2328 wrote: 
> 
> 
> 
>
> Perhaps. When using Nasm, the segfaults are *my* fault. This might tend
> to demoralize the beginner...

That is a deep and sobering epiphany.

> 
> 
>
> Yes. My mistake - I should have left that until after they've learned
> assembly language... :)

There is always room for a "Catch-22" no matter what the goal is.
Building a staircase requires one to follow a series of steps in order
to construct a series of steps.  :)

>
> My "Clueless Newbie's Guide to Hello World in Nasm" once had a "chapter
> two", in which every "mov", etc. was a link to the instruction in the
> Nasm manual, and every "int" was a link to RBIL. Then Nasm and RBIL both
> updated, breaking all my links...

Interesting solution.  How did the readers react to it?

> and work up from there (Jonathan Bartlett's PGU, for example). But AoA
> is aimed at a "course" which lasts some number of ws that will fit in
> 4 bits. This changes the picture! In particular, if the course is
> supposed to be "Computer Architecture and Assembly Language", you might
> like to be able to write an assembly language program that explored some
> computer architecture... This is where "the_hard_parts.inc" comes in.
> "the_OS_specific_parts.inc" has value on its own, of course.

Some taste of OS-interfacing is desirable, but I'm not sure I agree
that it should be present throughout the main course.
 
>
> Not really...

I noticed that too.  But it is factual for *that* specific instance of
data.

>
> message db "Hello, World of assembly language (and C)", 10, 0

Well, it is ALWAYS going to be "(and _something_)" no matter how you
approach it!  *Your* way, it is either (and LinuxAPI) or (and
WinAPI).  The only way to do away with the (and ___) is to do it on
bare metal or in a simulator.  A line must be drawn in the sand
somewhere.

An epiphany has recently come to me.  I guess, due to the many
questions we witness over the years, I convinced myself that *some*
type of additional material (examples, tutorial, or wiki, etc.) is
indeed needed.  Now I am wondering if this is a wrong conclusion.
Perhaps what those sers really need is that which they already have
access to -- those books and online material that already exist; the
classrooms (complete with teacher and fellow students) that are
available to them.

Nathan.

On Feb 25, 5:18 pm, DaveR  <spamt...@crayne.org> wrote:
> Hi
>
> I'm just starting out trying to learn assembler, using HLA and the
> "Art of Assembler".  I am having problems executing very simple demo
> programs.
>
> A hello world program works, however as soon as I introduce a
> variable, I get a segfault.  I have given a working and broken example
> below.
>
> Apologies if I have done something stupid(!) , but any help would be
> appreciated.  Please let me know if you need anymore information to
> help...
>
> Kind Regards
> David
>
> [david@beechwood:~/local/AoA/Volume1/Ch02 ] $ uname -a
> Linux beechwood.home 2.6.23.15-137.fc8 #1 SMP Sun Feb 10 17:48:34 EST
> 2008 i686 i686 i386 GNU/Linux
>
> ====WORKING=====
>
> [david@beechwood:~/local/AoA/Volume1/Ch02 ] $ more HelloWorld.hla
> program helloWorld;
> #include( "stdlib.hhf" );
>
> begin helloWorld;
>
>     stdout.put( "Hello, World of Assembly Language", nl );
>
> end helloWorld;
> [david@beechwood:~/local/AoA/Volume1/Ch02 ] $ hla -v HelloWorld.hla
> HLA (High Level Assembler)
> Use '-license' to see licensing information.
> Version Version 1.99 build 12923 (prototype)
> ELF output
> OBJ output using internal FASM back-end
> -test active
>
> HLA Lib Path:     /home/david/local/hla/hlalib/hlalib.a
> HLA include path: /home/david/local/hla/include
> HLA temp path:
> Files:
> 1: HelloWorld.hla
>
> Compiling 'HelloWorld.hla' to 'HelloWorld.o'
> using command line:
> [hlaparse -level=high  -v -sf -celf -test "HelloWorld.hla"]
>
> ----------------------
> HLA (High Level Assembler) Parser
> use '-license' to view license information
> Version Version 1.99 build 12923 (prototype)
> -t active
> File: HelloWorld.hla
> Output Path: ""
> Language Level: high
>
> Compiling "HelloWorld.hla" to "HelloWorld.o"
> Compilation complete, 14837 lines,   0.214 seconds,   69332 lines/
> second
> Using flat assembler version C1.66
> 3 passes, 1499 bytes.
> ----------------------
> Linking via [ld    -o "HelloWorld"  "HelloWorld.o" "/home/david/local/
> hla/hlalib/hlalib.a"]
> [david@beechwood:~/local/AoA/Volume1/Ch02 ] $ ./HelloWorld
> Hello, World of Assembly Language
>
> ====BROKEN=====
>
> [david@beechwood:~/local/AoA/Volume1/Ch02 ] $ more
> HelloWorldWithVar.hla
> program helloWorld;
> #include( "stdlib.hhf" );
>
> static
>     InitDemo:       int32 := 5;
>
> begin helloWorld;
>
>     stdout.put( "Hello, World of Assembly Language", nl );
>     stdout.put( "InitDemo's value is ", InitDemo, nl );
>
> end helloWorld;
> [david@beechwood:~/local/AoA/Volume1/Ch02 ] $ hla -v
> HelloWorldWithVar.hla
> HLA (High Level Assembler)
> Use '-license' to see licensing information.
> Version Version 1.99 build 12923 (prototype)
> ELF output
> OBJ output using internal FASM back-end
> -test active
>
> HLA Lib Path:     /home/david/local/hla/hlalib/hlalib.a
> HLA include path: /home/david/local/hla/include
> HLA temp path:
> Files:
> 1: HelloWorldWithVar.hla
>
> Compiling 'HelloWorldWithVar.hla' to 'HelloWorldWithVar.o'
> using command line:
> [hlaparse -level=high  -v -sf -celf -test "HelloWorldWithVar.hla"]
>
> ----------------------
> HLA (High Level Assembler) Parser
> use '-license' to view license information
> Version Version 1.99 build 12923 (prototype)
> -t active
> File: HelloWorldWithVar.hla
> Output Path: ""
> Language Level: high
>
> Compiling "HelloWorldWithVar.hla" to "HelloWorldWithVar.o"
> Compilation complete, 15683 lines,   0.223 seconds,   70327 lines/
> second
> Using flat assembler version C1.66
> 3 passes, 1644 bytes.
> ----------------------
> Linking via [ld    -o "HelloWorldWithVar"  "HelloWorldWithVar.o" "/
> home/david/local/hla/hlalib/hlalib.a"]
> [david@beechwood:~/local/AoA/Volume1/Ch02 ] $ ./HelloWorldWithVar
> Hello, World of Assembly Language
> InitDemo's value is Segmentation fault

I am wondering if we have finally stumbled upon the cause of David's
troubles?  Could it be that HLA is marking the '.text' sections of ELF
object files as type NOBITS (what a '.bss' section is usually typed
as) instead of the typical setting of PROGBITS?

I suspect that some versions of LD give a warning [ ld: section
`.text' type changed to PROGBITS ], while other versions make the
change silently, and still another version (which David was the
unlucky victum of) simply leaves the setting "as is" and thus
producing a binary with those items nulled-out.

http://www.masm32.com/board/index.php?topic=8873.0

Nathan.

nbaker2328 wrote:

... 
>
>
> I am wondering if we have finally stumbled upon the cause of David's
> troubles?  Could it be that HLA is marking the '.text' sections of ELF
> object files as type NOBITS (what a '.bss' section is usually typed
> as) instead of the typical setting of PROGBITS?

How come I didn't notice that??? Yeah, HLA *is* flagging some .text
sections (but not all) as NOBITS! I'm quite sure that this is "wrong,
period".

> I suspect that some versions of LD give a warning [ ld: section
> `.text' type changed to PROGBITS ], while other versions make the
> change silently, and still another version (which David was the
> unlucky victum of) simply leaves the setting "as is" and thus
> producing a binary with those items nulled-out.

That seems probable. I can confirm that some versions of ld (2.15.90.0.3
here) do silently change a section *named* .text from writeable to
readonly. I'll bet it changes NOBITS to PROGBITS too. A NOBITS .text
section makes no sense at all to me... it's almost a "bug" in ld *not*
to change it... but that *is* what we said...

> http://www.masm32.com/board/index.php?topic=8873.0

I'm embarrassed that the "evil board" spotted this and I didn't (having
a version of ld that complains is a help...). Well... given the "scent",
this shouldn't be too hard to track down...

This doesn't solve the issue of the legendary, perhaps mythical, "build
12923", but I think you've hit it. Nice work, Nathan!

Best,
Frank

On Feb 25, 2:18_pm, DaveR  <spamt...@crayne.org> wrote:
> Hi
>
> I'm just starting out trying to learn assembler, using HLA and the
> "Art of Assembler". _I am having problems executing very simple demo
> programs.
>

I've not followed this through to the end to see if the answer has
been posted here, but the problem seems to be in the code that FASM
generates under Linux.  The quick work-around, until I update FASM to
work properly, is to use Gas as the back-end assembler under Linux.
Try compiling your programs with the "-xg" command-line option and see
if that helps.
hLater,
Randy Hyde