Seg fault with hla 1.99 on Fedora 8 linux

DaveR wrote:
> Ok - thanks for the help guys! - I'll do my best.  As you say, whilst
> I'm happy to give NASM a go ( once I know a bit of assembler ) it
> would be nice to get HLA working on my linux box, as it would make
> following the book a lot easier ( BTW - I'm finding the book really
> good and well layed out - only having done high level languages
> before, this is all very enlightening... :-> )
>
> Ok - now for the info that you wanted:
>
> First - yes my install of FC8 is 32 bit.

Yeah... I'd have known that if I'd read your original post more carefully.

> Second - install paths.  I have the following setup
>
> HLA 1.99 installed in /home/david/local/hla1.99
> HLA 1.97 installed in /home/david/local/hla1.97
> A symlink from /home/david/local/hla -> hla1.9X (depending on which
> version I'm testing)

Chuck has pointed out some potential problems with this. Randy's
"packaging system" is not "the way you do it in Unix". A long time ago,
I tried installing HLA under /home/fbk, with the executables in /usr/bin
or /usr/local/bin... I *thought* I had path and environment variables
set "right" for what I was trying to do, but it behaved as if some
component were hard-coded into... ??? I forget what the "diagnostic"
was. Since then, I've done it "Randy's way" - as root, get into "/" and
"tar zxf /home/fbk/hla-1.99.tar.gz" (I add the version info when I
download it). (certain earlier versions, you had to be in "/usr", not
"/") This has worked well enough so I haven't gone back to trying it the
way I'd "like" to install it.

> and the following env vars set:
> [david@beechwood:~/local ] $ env | grep hla
> hlalib=/home/david/local/hla/hlalib/hlalib.a
> hlainc=/home/david/local/hla/include
> PATH=/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/home/david/local/
> hla:/home/david/bin

This looks right... Chuck quotes these as "HLAINC" and "HLALIB" - lasi I
checked, they *had* to be lowercase - yet another "unusual" feature of
"Randy's system".

I really think this "ought" to work the way you're doing it, but if all
else fails, try it the "HLA way" and see if it helps...

> Third - core dumps - I have done a little bit of C programming so have
> some experience of gdb and examining core dumps, however , I'm not
> really sure how this translates to assembler...

Well, best thing is to avoid 'em, I guess... Still on my "TODO" list to
learn more about this...

> ...  Having just written the out the above, whilst trying to get some
> more info I have now found a way to make it work , by switching the
> assemblers
>
> With internal FASM:
>
> [david@beechwood:~/local/AoA/Volume1/Ch02 ] $ hla -xo
> HelloWorldWithVar.hla
> [david@beechwood:~/local/AoA/Volume1/Ch02 ] $ ./HelloWorldWithVar
> Hello, World of Assembly Language
> InitDemo's value is Segmentation fault (core dumped)
>
>
> With Gas:
>
> [david@beechwood:~/local/AoA/Volume1/Ch02 ] $ hla -xg
> HelloWorldWithVar.hla
> [david@beechwood:~/local/AoA/Volume1/Ch02 ] $ ./HelloWorldWithVar
> Hello, World of Assembly Language
> InitDemo's value is 5
>
>
> Any thoughts on why this might be ( although now I can get on with
> trying the examples :-> ... )?

On the face of it, you've discovered a bug in the code generation of
"internal Fasm". But... the funny build number, and the fact that HLA
seems to work "as-is" for other people makes me suspect some subtle
"mismatch" in the way you've got it installed. I'd expect a "diagnostic"
rather than a faulting executable - this is a "bug" in HLA, perhaps, but
not too unexpected (if that's what's happening).

At least now you've got two executables to compare - yourself or send
'em to someone - Randy, if it's really a bug in HLA. And you've got a
workaround so you can do the examples...

But I'm really puzzled by that build number... Here's what's working for
me (slightly pruned) - this is 1.99 (let's concentrate on that):

/usr/hla:
-rwxr-xr-x   1 root root   519176 2008-01-07 16:02 hla*
-rwxr-xr-x   1 root root  2191935 2008-01-07 16:02 hlaparse*

/usr/hla/hlalib:
-rw-r--r--  1 root root 1575420 2008-01-07 16:09 hlalib.a

Sizes match, at least?

Nathan's suggestion that the build number suggests 1.10x masquerading as
1.99 is worrisome. HLA is in "version number hell" right now, so mixups
(not necessarily yours) are possible...

> Many thanks for all your help and advice!

No problem. Some people do crossword puzzles. :) If you get good at
this, we'll be coming to *you* for help and advice!

Best,
Frank

Sorry - I did't make myself clear

/home/david/local/hla1.99 and /home/david/local/hla1.97

are directories each of which contains the full hla installation. So I
have

/home/david/local/hla1.99/hla
/home/david/local/hla1.99/hlaparse
/home/david/local/hla1.99/hlalib/hlalib.a
/home/david/local/hla1.99/include

and

/home/david/local/hla1.97/hla
/home/david/local/hla1.97/hlaparse
/home/david/local/hla1.97/hlalib/hlalib.a
/home/david/local/hla1.97/include

and the symlink is

[david@beechwood:~/local ] $ ls -l hla
lrwxrwxrwx 1 david users 7 2008-02-26 09:32 hla -> hla1.99/

The symbolic link just allows me to switch versions , as all my
paths and env variables just point to /home/david/local/hla/   I don't
copy anything into /home/david/local/hla/ , so I'm pretty confident
that I'm not using mixed versions.

Any thoughts on why switching backend assemblers makes a difference?

Regards
David

Hi Frank - looks like our post's crossed!

I'm pretty sure my setup's ok - but I've gone with the "vanilla" hla
setup to remove any doubt:

[root@beechwood:/usr/hla ] # ls -l /usr/hla/hla /usr/hla/hlaparse /usr/
hla/hlalib/hlalib.a
-rwxr-xr-x 1 root root  519176 2008-01-07 21:02 /usr/hla/hla
-rw-r--r-- 1 root root 1575420 2008-01-07 21:09 /usr/hla/hlalib/
hlalib.a
-rwxr-xr-x 1 root root 2191935 2008-01-07 21:02 /usr/hla/hlaparse

The file sizes ( and timestamps - ignoring timezones ) match, which
looks good.
Environment variables below:

[david@beechwood:~ ] $ env | grep hla
hlalib=/usr/hla/hlalib/hlalib.a
hlainc=/usr/hla/include
PATH=/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/usr/hla:/home/
david/bin

And the switch assemblers test repeated:

[david@beechwood:~/local/AoA/Volume1/Ch02 ] $ which hla
/usr/hla/hla
[david@beechwood:~/local/AoA/Volume1/Ch02 ] $ hla -xo
HelloWorldWithVar.hla
[david@beechwood:~/local/AoA/Volume1/Ch02 ] $ ./HelloWorldWithVar
Hello, World of Assembly Language
InitDemo's value is Segmentation fault
[david@beechwood:~/local/AoA/Volume1/Ch02 ] $ hla -xg
HelloWorldWithVar.hla
[david@beechwood:~/local/AoA/Volume1/Ch02 ] $ ././HelloWorldWithVar
Hello, World of Assembly Language
InitDemo's value is 5

So I have uploaded the hla file and the output from both compiles to
http://hla.webhop.org/ for anyone who want a closer look.

Do you know the best way to raise this with Randy?  Bug on
Sourceforge / email etc?

Back to the books now....

Kind Regards
David

On Feb 27, 9:25 pm, Charles Crayne  <spamt...@crayne.org> wrote:
>
> I have never [deliberately] tried mixing elements from different
> releases, nor do I recall the issue being discussed, but I don't think
> that it is a good idea.

There is generally no problem resulting from mixing different library
releases with the compiler.  It does, however, make things more
difficult when one mixes things and expects others to be able to do a
"remote diagnosis" but does not reveal all of the ingedients in his
special mix.

Nathan.

On Feb 27, 8:08 am, Frank Kotler  <spamt...@crayne.org> wrote:
> 
> 
>
> If Nasm had a fan club, I'd be president (maybe "maximum leader", even),
> so I won't argue with that suggestion. However... Nasm isn't going to
> correspond well with AoA, which is what David would like to do...
>

Nasm is an assembler isn't it?  AoA teaches assembly, right?

It should be possible to convert most of the AoA examples to Nasm
source using the C library for the I/O stuff.  Alternatively, one
could convert them directly to C code using inline assembly.

Nathan.

On Feb 28, 6:25 pm, DaveR  <spamt...@crayne.org> wrote:
> Hi Frank - looks like our post's crossed!
>
> I'm pretty sure my setup's ok - but I've gone with the "vanilla" hla
> setup to remove any doubt:
>
> [root@beechwood:/usr/hla ] # ls -l /usr/hla/hla /usr/hla/hlaparse /usr/
> hla/hlalib/hlalib.a
> -rwxr-xr-x 1 root root  519176 2008-01-07 21:02 /usr/hla/hla
> -rw-r--r-- 1 root root 1575420 2008-01-07 21:09 /usr/hla/hlalib/
> hlalib.a
> -rwxr-xr-x 1 root root 2191935 2008-01-07 21:02 /usr/hla/hlaparse

Why are you running as root user???

>
> Do you know the best way to raise this with Randy?  Bug on
> Sourceforge / email etc?
>

Randall Hyde <randyhyde (at) earthlink (dot) net>

Bug reports for v1.x can be filed at:
http://sourceforge.net/tracker/?gro...04&atid=1032333

You may also want to test v1.101 to see if it still shows up there --
if so, then report the results here:
http://sourceforge.net/tracker/?gro...727&atid=836524

Nathan.

DaveR wrote:
> Hi Frank - looks like our post's crossed!

Yeah, it happens...

> I'm pretty sure my setup's ok - but I've gone with the "vanilla" hla
> setup to remove any doubt:

Okay... FWIW, I tried it "your way" (more or less -
/home/fbk/usr/hla/lahdeedah", not "local") and it worked fine. Next
step, try putting hla and hlaparse someplace "normal"... haven't gotten
to trying that...

> [root@beechwood:/usr/hla ] # ls -l /usr/hla/hla /usr/hla/hlaparse /usr/
> hla/hlalib/hlalib.a
> -rwxr-xr-x 1 root root  519176 2008-01-07 21:02 /usr/hla/hla
> -rw-r--r-- 1 root root 1575420 2008-01-07 21:09 /usr/hla/hlalib/
> hlalib.a
> -rwxr-xr-x 1 root root 2191935 2008-01-07 21:02 /usr/hla/hlaparse
>
> The file sizes ( and timestamps - ignoring timezones ) match, which
> looks good.
> Environment variables below:
>
> [david@beechwood:~ ] $ env | grep hla
> hlalib=/usr/hla/hlalib/hlalib.a
> hlainc=/usr/hla/include
> PATH=/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/usr/hla:/home/
> david/bin
>
> And the switch assemblers test repeated:
>
> [david@beechwood:~/local/AoA/Volume1/Ch02 ] $ which hla
> /usr/hla/hla
> [david@beechwood:~/local/AoA/Volume1/Ch02 ] $ hla -xo
> HelloWorldWithVar.hla
> [david@beechwood:~/local/AoA/Volume1/Ch02 ] $ ./HelloWorldWithVar
> Hello, World of Assembly Language
> InitDemo's value is Segmentation fault
> [david@beechwood:~/local/AoA/Volume1/Ch02 ] $ hla -xg
> HelloWorldWithVar.hla
> [david@beechwood:~/local/AoA/Volume1/Ch02 ] $ ././HelloWorldWithVar
> Hello, World of Assembly Language
> InitDemo's value is 5
>
> So I have uploaded the hla file and the output from both compiles to
> http://hla.webhop.org/ for anyone who want a closer look.

Now we're cooking with Gas! :) Actually it's the Fasm version I'm
interested in. A preliminary analysis of your "Fasm" executable shows
that where we should be in CONV_I64TOBUF, we're in a block of zeros...
Go boom!

*Why* remains a mystery. My version of 1.99 reads *just* like your
original post, right up to "Version Version"... but my build number is
12922 and yours is 12923... weird... (I obtained 1.100 and verified that
it *doesn't* report 1.99 and build 12923, so that's not it...).

I linked your .o file "ld -o hwvar HelloWorldWithVar.o
/usr/hla/hlalib/hlalib.a"... and it worked perfectly.

Lemme see... Your library's corrupted. No, then it wouldn't work with
Gas, either.

Your ld is choking on something my ld likes. Something HLA gets right
with "-xg", but gets "wrong" with the internal Fasm (possibly only in
"build 12923"?). Improbable as that seems, I can't rule it out, and
can't think of anything else.

I'll see if I can get into your .o file, Fasm vs Gas, byte by byte, but
I probably won't spot anything...

> Do you know the best way to raise this with Randy?  Bug on
> Sourceforge / email etc?

The bugtracker on SourceFrog would be great... but I think it's mostly
for the new library, and versions 1.100+ of HLA. Wouldn't hurt. Randy's
SF username is "rhydehla", and you can reach any SourceForge user at
"users.sf.net". (or randyhyde at earthlink dot net) I'll cc this to the
Yahoo group - where he *is* posting recently. You might want to join
that group anyway:

http://tech.groups.yahoo.com/group/aoaprogramming/

Thanks for posting those files - gives us something we can sink our
teeth into, even if the "why" isn't obvious - you're not dreamin', it
really does segfault, yet the .o file works okay here... Use "-xg" for
the examples, I guess...

Best,
Frank

nbaker2328 wrote:
> On Feb 27, 8:08 am, Frank Kotler  <spamt...@crayne.org> wrote:
> 
>
> Nasm is an assembler isn't it?  AoA teaches assembly, right?

Dunno. Nasm is an assembler. Nasm won't assemble what AoA teaches.
Conclusion?

> It should be possible to convert most of the AoA examples to Nasm
> source using the C library for the I/O stuff.  Alternatively, one
> could convert them directly to C code using inline assembly.

Sure, "echo the answer is 5" is possible, too. Or "just call printf". Or
we could use the HLA library (stepping through it, Wolfgang's right -
detoured) from Nasm, too, or vid's fasmlib (which, despite the name, is
for Nasm too). Maybe David doesn't care too much if it runs on
Windows... we could do it with Jeff Owens' lib, or we could do it
without no steenking library.

Start with something simple... Linux only. We can add ExitProcess and
WriteFile later...

Best,
Frank

; nasm -f elf hwint.asm
; ld -o hwint hwint.o

global _start

section .data

hiya db "Hello, World of (real) Assembly Language!", 10
; "$", in this context, means "here", the current offset
; in the file, so this calculation counts characters.
hiya_len equ $ - hiya

;    ans db "InitDemo's value is Segmentation Fault", 10
; naw, that's *too* simple
ans db "InitDemo's value is "
ans_len equ $ - ans

InitDemo dd 5

section .text
_start:
mov ecx, hiya
mov edx, hiya_len
call write_stdout

mov ecx, ans
mov edx, ans_len
call write_stdout

mov eax, [InitDemo]
call showeaxd

call newline
xor eax, eax		; claim "no error".

exit:
mov ebx, eax		; error/return code in ebx (bl, actually)
mov eax, 1			; __NR_exit
int 80h
;-----------------------

;---------------------------------
showeaxd:
pusha			; save caller's regs

sub esp, 10h		; make buffer on stack
lea ecx, [esp + 10h]	; start at "end" of buffer
mov ebx, 10			; for decimal, divide by 10
xor esi, esi		; length counter
.top:
dec ecx			; work towards "front" of buffer
xor edx, edx		; "div" works with edx:eax!
div ebx			; quotient in eax, remainder in edx
add dl, '0'			; convert number to ascii char
mov [ecx], dl		; store it
inc esi			; count it
or eax, eax			; quotient zero?
jnz .top			; do more

mov edx, esi		; length in edx
call write_stdout		; print it

add esp, 10h		; free the buffer

popa			; restore caller's regs
ret
;---------------------------------

;-------------------
newline:
pusha
push 10			; linefeed
mov ecx, esp		; stack is the buffer
mov edx, 1			; just one
call write_stdout
add esp, 4			; free buffer
popa
ret
;------------------

;------------------
write_stdout:
mov ebx, 1			; STDOUT
mov eax, 4			; __NR_write
int 80h
ret
;-------------------

Frank Kotler wrote:


> Start with something simple... Linux only. We can add ExitProcess and
> WriteFile later...
>
> Best,
> Frank
>
> ; nasm -f elf hwint.asm
> ; ld -o hwint hwint.o
>

Couldn't resist and had to convert your example to a more readable NASM
syntax. It's still not what I would call an usable syntax for writing
programs, but anything is better than Intel syntax:


 ;=======================================
====================================
; nasm -O99 -f bin -o hwint  hwint.asm
%include "mac.inc" ; ftp://137.193.64.130/pub/assembler/xlinux.zip
 ;=======================================
====================================
seg 32
orig equ $08048000
code_addr equ orig
code_offset equ 0
section .text vstart=code_addr
;--------------------------- ELF header -----------------------------------
dc.l  $464c457f,$00010101,0,0,$00030002,1,main
,$34,0,0,$00200034,2,0
dc.l  1,code_offset,code_addr,code_addr,code_f
ilez,code_memsz,5,4096
dc.l  1,data_offset,data_addr,data_addr,data_f
ilez,data_memsz,6,4096
;--------------------------- code ------------------------------------------


main:   move.l  hiya,r2
move.l  hiya_len,r1
bsr.l   write_stdout

move.l  ans,r2
move.l  ans_len,r1
bsr.l   write_stdout

move.l  [InitDemo],r0
bsr.l   showeaxd

bsr.l   newline
eor.l   r0,r0           ; claim "no error".

exit:   move.l  r0,r3           ; error/return code in ebx (bl, actually)
move.l  1,r0            ; __NR_exit
trap    $80


showeaxd:
movem.l r0-r7,-[sp]     ; save caller's regs

sub.l   $10,r7          ; make buffer on stack
lea.l   [r7+$10],r2     ; start at "end" of buffer
move.l  10,r3           ; for decimal, divide by 10
eor.l   r5,r5           ; length counter

.top: dec.l   r2              ; work towards "front" of buffer
eor.l   r1,r1           ; "div" works with edx:eax!
divu.l  r3,r1|r0        ; quotient in eax, remainder in edx
add.b   '0',r1          ; convert number to ascii char
move.b  r1,[r2.l]       ; store it
inc.l   r5              ; count it
or.l    r0,r0           ; quotient zero?
bne.b   .top            ; do more

move.l  r5,r1           ; length in edx
bsr.l   write_stdout    ; print it

add.l   $10,r7          ; free the buffer

movem.l [sp]+,r0-r7     ; restore caller's regs
rts.l

newline:movem.l r0-r7,-[sp]
moveq.l 10,-[sp]        ; linefeed
move.l  r7,r2           ; stack is the buffer
move.l  1,r1            ; just one
bsr.l   write_stdout
addq.l  4,r7            ; free buffer
movem.l [sp]+,r0-r7
rts.l

write_stdout:
move.l  1,r3            ; STDOUT
move.l  4,r0            ; __NR_write
trap    $80
rts.l

 ;=======================================
====================================

;--------------------------- constant data ---------------------------------
hiya: dc.b "Hello, World of (real) Assembly Language!", 10
hiya_len equ $-hiya

ans: dc.b "InitDemo's value is "
ans_len equ $-ans

InitDemo: dc.l 5
;---------------------------------------------------------------------------

align 4
code_memsz equ $-$$
code_filez equ code_memsz
data_addr equ (orig+code_memsz+4095)/4096*4096 + (code_filez % 4096)
data_offset equ code_filez
section .data vstart=data_addr

;--------------------------- initialized data ------------------------------

;---------------------------------------------------------------------------

idat_memsz equ $-$$
bss_addr equ data_addr+ ($-$$)
section .bss vstart=bss_addr

;--------------------------- uninitialized data ----------------------------

;---------------------------------------------------------------------------

udat_memsz equ $-$$
data_memsz equ idat_memsz + udat_memsz
data_filez equ idat_memsz
 ;=======================================
====================================

On Feb 29, 3:52 am, Frank Kotler  <spamt...@crayne.org> wrote:
> 
>
> Dunno. Nasm is an assembler. Nasm won't assemble what AoA teaches.
> Conclusion?

One should not use Nasm to learn assembly!  :)

> ; nasm -f elf hwint.asm
> ; ld -o hwint hwint.o

Your code assumes that "AoA student" knows what "inc, call, jnz, xor,
and etc." is this early in the book.  A few chapters in, it covers
some basic instructions.  My conversion of it suffers the same
problem.  Guess it'd be best to stuff some macros away into an include
file...

Nathan.

Original HLA example:

program DemoMOVaddSUB;



#include( "stdlib.hhf" );



static



i8:     int8    := -8;

i16:    int16   := -16;

i32:    int32   := -32;



begin DemoMOVaddSUB;



// First, print the initial values

// of our variables.



stdout.put



(



nl,



"Initialized values: i8=", i8,



", i16=", i16,



", i32=", i32,



nl



);



// Compute the absolute value of the

// three different variables and

// print the result.

// Note, since all the numbers are

// negative, we have to negate them.

// Using only the MOV, ADD, and SUB

// instruction, we can negate a value

// by subtracting it from zero.



mov( 0, al );   // Compute i8 := -i8;



sub( i8, al );



mov( al, i8 );







mov( 0, ax );   // Compute i16 := -i16;



sub( i16, ax );



mov( ax, i16 );







mov( 0, eax );  // Compute i32 := -i32;



sub( i32, eax );



mov( eax, i32 );




// Display the absolute values:





stdout.put



(



nl,



"After negation: i8=", i8,



", i16=", i16,



", i32=", i32,



nl



);





// Demonstrate ADD and constant-to-memory

// operations:





add( 32323200, i32 );



stdout.put( nl, "After ADD: i32=", i32, nl );







end DemoMOVaddSUB;



; The demoMOVaddSUB example converted from AoA.
;
; nasm -f elf -o demo.o demo.asm
; gcc -o demo demo.o

section .data

i8:		db	-8
i16:		dw	-16
i32:		dd	-32
initVal:	db	' Initialized values:', 10, 0
negVal:	db	' After negation:', 10, 0
addVal:	db	' After addition:', 10, 0
str8:	db	'  i8 = %d', 10, 0
str16:	db	'  i16 = %d', 10, 0
str32:	db	'  i32 = %d', 10, 0

section .text

global main
extern printf

main:

; First, print the initial values

; of our variables.


lea eax, [initVal] ; or use 'mov eax, initVal'
push eax
call printf
add esp, 4

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

movsx eax, WORD [i16] ; sign-extended mov
push eax
lea eax, [str16]
push eax
call printf
add esp, 8

mov eax, LONG [i32] ; a regular mov
push eax
lea eax, [str32]
push eax
call printf
add esp, 8

; Compute the absolute value of the

; three different variables and

; print the result.

; Note, since all the numbers are

; negative, we have to negate them.

; Using only the MOV, ADD, and SUB

; instruction, we can negate a value

; by subtracting it from zero.


mov al, 0
sub al, BYTE [i8]
mov BYTE [i8], al

mov ax, 0
sub ax, WORD [i16]
mov WORD [i16], ax

mov eax, 0
sub eax, LONG [i32]
mov LONG [i32], eax

; Display the absolute values:


lea eax, [negVal]
push eax
call printf
add esp, 4

movsx eax, BYTE [i8]
push eax
lea eax, [str8]
push eax
call printf
add esp, 8

movsx eax, WORD [i16]
push eax
lea eax, [str16]
push eax
call printf
add esp, 8

mov eax, LONG [i32]
push eax
lea eax, [str32]
push eax
call printf
add esp, 8

; Demonstrate ADD and constant-to-memory

; operations:


add LONG [i32], 32323200

lea eax, [addVal]
push eax
call printf
add esp, 4

mov eax, LONG [i32]
push eax
lea eax, [str32]
push eax
call printf
add esp, 8

ret