[Info-vax] Status of the PostgreSQL port?

[John Reagan]

On Tuesday, June 30, 2015 at 4:15:43 AM UTC-4, hb wrote:
> On 06/30/2015 12:46 AM, John Reagan wrote:

> > 
> > I absolutely would support changes to the linker to help it resolve
> lowercase aliases.  I'd even consider some tool (perhaps the linker itself)
> to modify an existing symbol vector.
> 
> I'm sure there was a discussion on case-tolerant symbol resolution when
> the linker was ported to I64. I don't remember the arguments. Obviously
> it was decided to keep the exact match behavior. And, that's what I
> think the linker in general should do.
> 
> If the owner of a shareable image exported a symbol "FOO" and a
> developer codes a C application with calling "foo", it is simply wrong
> and should not work. (Today it only works, because, by default, external
> symbols are "uppercased" and, obviously, open source compiled with
> /NAMES=AS_IS makes this fail).

I was thinking of an option for the shareable image to say "match the names case-insensitively" so you don't have to double up the symbol vector.

Personally, I think /NAMES=AS_IS as the last-resort.  I've compiled most of LLVM without needed /NAMES=AS_IS at all (I do use /NAMES=SHORT).


> That said and putting my in-theory-hat off, I don't think that the
> support request is for case blind symbol resolution, in general. And I
> see the problem and saw linker options files with lots of alias names
> defined as well as C include files which have a lot of #defines to get
> this right. From my point of view, to help or support some case-tolerant
> resolution, one option could be to tell the linker that a case blind
> match is wanted: a flag either in the object module or in the symbol,
> set on request. Another option would be to have a linker option to map
> symbols. So with the shareable image an options file could be provided
> to define the mapping, or the developer of the application writes one
> for the interfaces which are used. Then the owners of the code are still
> responsible for using the correct interface.  A much simpler option may
> be to let the linker, on request, generate matching lower- or uppercase
> symbols for each exported symbol in a symbol_vector option. OK, just
> some thoughts, open for discussion. This would be all for the x86_64
> port, although I suspect, some people would like to have that for
> Alpha/I64 as well.

Exactly.  Good ideas.

> 
> On the other hand I don't understand what in this context you mean with
> "some tool ... to modify an existing symbol vector". The symbol vector
> itself doesn't contain any symbol. On I64, for procedures, it contains
> the address of the function descriptor (which resides in short data). I
> don't think you want to modify that. Do you want to modify the symbol
> table? As you probably know, the symbols are only used by the linker and
> lib$fis, the image activator doesn't use or need any symbol. (That's the
> current or traditional VMS implementation and it is what some people
> refer to as "early binding" which is different from Unix where the
> loader uses the symbol for a "late binding").
> 
> The current tool to change an image is "SET IMAGE". There are no options
> to modify anything related to symbols: striping off the symbols requires
> a re-link.

Yes, SET IMAGE to toggle some of the options above off-and-on. As for "modifying", I can imaging wanting to extend the vector to add an alias (perhaps a mixed-case name) to resolve a missing symbol at link-time.  I wouldn't want to randomly mess with existing entries in the vector.