Re: 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

.

Relevant Pages

  • Re: Insert a byte
    ... In the assembly world (HLA ... *your* assembler won't deal with libraries (without ... I can always install an additional TV card in my PC then I can also watch ... And which of the above mentioned libraries are available for al the different ...
    (alt.lang.asm)
  • Re: Insert a byte
    ... In the assembly world (HLA ... If you install an assembler you normal don't get any getc/putc. ... If your code calls libraries, and you don't link in the libraries, your code *is* buggy/incomplete! ...
    (alt.lang.asm)
  • Re: HLA install
    ... You choose to manually install HLA rather than running hlasetup.exe ... > thingy as I have all my environments vars set correctly. ... > I am due to do a big disk clean up soon and reformat my C drive, ...
    (alt.lang.asm)
  • Re: Problem with hla
    ... Linux and Windows of course, incorporating the HLA binaries, includes, ... You also have to set up environment variables and paths. ... I ought to do an install package for Linux. ...
    (alt.lang.asm)
  • Re: HLA in c, c++ code?
    ... T.M. Sommers wrote: ... and then install it with a 'make install'. ... I think I could install the rebuilt library in /usr/hla/hlalib *without* being root... ... I don't know if HLA would profit from that or not. ...
    (alt.lang.asm)