[Info-vax] Status of the PostgreSQL port?

[Stephen Hoffman]

On 2015-06-30 08:15:40 +0000, hb said:

> 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).

Ayup.   The proper behavior is to use the case that the user provided 
both in the code and in the vector, and to not alter it.  
Unfortunately, adding case-blindness adds a bag of hurt.

> The owner of the interface should either export both symbols "FOO" and 
> "foo" or the developer should code a call to "FOO".

Ayup.  The call should be to whatever was coded.  The aliases are a 
sometimes-useful hack, and should currently be used to allow 
language-insensitive languages to call the routines.  That if the 
linker itself doesn't provide a gratuitous upcase by default.

> That's what the alias name in the linker option symbol_vector offers 
> and/or on the other hand one might want to use #defines to continue 
> using "foo" in the sources. In other words, the owner of the shareable 
> image and the developer are responsible to offer and use the correct 
> interface. It's not the job of the linker to make a match just by 
> magic: do what I mean.

Ayup.  It's where the linker and the compilers start to uppercase stuff 
that gets ugly.  And as has been discussed recently, there is not a 
clean mapping.

> 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.

The headers have a lot of #define definitions and SDL has /VMS_DEV and 
/C_DEV because that was the most expedient workaround.  Compatibility 
and complexity and all.

> 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.

Let the linker default to case-preserve with the creation of an 
uppercase alias where that differs, and log a diagnostic when there's a 
name collision; symbols that differ by case.  Allow the user to shut 
off the implicit upcasing within the linker, and silently ignore cases 
where the alias itself is a collision.  Don't ignore cases where some 
other unrelated symbol or unrelated alias is the collision.

> 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").

There are tools other than the linker and lib$find_image_symbol that 
use the external symbols.  I'm in the midst of writing one 
<http://labs.hoffmanlabs.com/node/1906>, as a workaround for having 
uppercase-only symbols in the symbol table.   Currently sorting out the 
handling of data entries as part of an update.  There are other tools 
around that access the symbols, as well.

> 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.

Beyond its current capabilities, SET IMAGE (in conjunction with some 
work in the linker and the image activator, and calls to read and write 
the settings, and adjustments to the image verification tools to 
optionally ignore this data) would be one obvious way to access and 
embed application-specific default settings, too.  This rather than 
using the lib$initialize psect morass.   Create a user interface for 
this and other features.



-- 
Pure Personal Opinion | HoffmanLabs LLC