Path: utzoo!attcan!uunet!comp.vuw.ac.nz!andrew
From: andrew@comp.vuw.ac.nz (Andrew Vignaux)
Newsgroups: comp.sys.hp
Subject: Re: 9000/835 loader and assembler problems
Summary: Thanks
Message-ID: <1989Jun9.084144.21407@comp.vuw.ac.nz>
Date: 9 Jun 89 08:41:44 GMT
References: <14870@comp.vuw.ac.nz> <1340056@hpclmar.HP.COM> <3770013@hpcllak.HP.COM>
Reply-To: andrew@comp.vuw.ac.nz (Andrew Vignaux)
Organization: Comp Sci, Victoria University, Wellington, New Zealand.
Lines: 50

This is great -- thanks to everyone who responded.  However, there are
a few comments I would like to make.

In article <1340056@hpclmar.HP.COM> mar@hpclmar.HP.COM (Michelle Ruscetta) writes:
> You MUST use the "exec_entry" field in the HPUX auxiliary header (which
> immediately follows the standard file header), or use the entry_offset
> field in the file header.

At least in the version of the loader I am using (A.01.04??) both of
the fields point at the "main" program's $START$.  I can't use the -e
option because I don't know the name of the initial function.  Is it
unreasonable to get ld to default to the "first" function in the
dynamically loaded file when -A is used?

BTW: My tmem+4 hack doesn't work if the loaded object does any
indirect function calls.  I should probably search around in the
symbol table to find the correct address & 03.

I had not realised that I needed a flush_cache() routine after my
load.  I had read the note after the SYNC instruction, thought "You'll
never catch me writing self-modifing code", and promptly forgot it.

I don't think I would have guessed about ld's multiple module feature.
I was using a wrapper around ld to strip the "data" off while the load
was going on, which was a bit slow and a little dangerous.  Things are
working a lot better (and faster) now.



My latest incremental loading problem is trying to use function
pointers in the main program that have been computed in the
dynamically loaded routine (here-in-after referred to as fred).
Shouldn't the address of a routine be the address of the export stub?
I suspect function pointers from the main program, being used in fred,
would have the same problem -- but, fortunately, I don't think I need to
do that.

Does setjmp/longjmp cope with multiple space programs?



BTW: adb doesn't like my incrementally loaded objects. (segmentation fault)

Does the loader need to generate a different import stub for every
call for the same routine?

Thanks,
  Andrew
-- 
Domain address: andrew@comp.vuw.ac.nz   Path address: ...!uunet!vuwcomp!andrew