Symbol file problem ? 
Author Message
 Symbol file problem ?

Out of curosity I deceided to try reimplement the Display
module of DOS386 Oberon with the aim of creating a new
version that would run at a higher resolution my SuperVGA card.
Since DOS386 Oberon does not include a Display.Mod file I
recreated the module using the definition generated from
Browser.ShowDef and by adding the appropriate export marks
and other things necessary to make it compile. Unfortunately
I could not find a way to create a new Display.Obj file without
also creating a new Display.Sym. The addition of a Display.Sym
file would of course have a new key and would invalidate all
the  client modules. I double checked my work to make sure
that I had not forgotten anything but that does not seem
to be the case. I suspect the problem is that my
sequence of exported objects is slightly from the orginal
module and so the one-pass compiler generates a slightly
different symbol file ( - although the browser gives the
same definiton for my new module and the previous one ).
It is at least sufficiently different so that the
simple byte-wise comparison of old symbol against
the new symbol file fails. If this is correct, than I
suggest there should be a compiler switch which would allow
a new  symbol file to be generated using the key of an
existing symbol file.

Whitney



Fri, 24 May 1996 23:30:43 GMT  
 Symbol file problem ?

Quote:

>The addition of a Display.Sym
>file would of course have a new key and would invalidate all
>the  client modules. I double checked my work to make sure
>that I had not forgotten anything but that does not seem
>to be the case. I suspect the problem is that my
>sequence of exported objects is slightly from the orginal
>module and so the one-pass compiler generates a slightly
>different symbol file ( - although the browser gives the
>same definiton for my new module and the previous one ).
>It is at least sufficiently different so that the
>simple byte-wise comparison of old symbol against
>the new symbol file fails. If this is correct, than I
>suggest there should be a compiler switch which would allow
>a new  symbol file to be generated using the key of an
>existing symbol file.

This would not help you. If there are differences in the symbol file, some
things will not be compatible (e.g. a variable may be at a different offset,
so you access the wrong variable, or the procedures may be in a different
order, so you call the wrong procedure, or a record may not have the correct
size, so you overwrite memory that has not been correctly allocated).

Marc-Michael Brandis
Institute for Computer Systems
ETH-Zentrum (Swiss Federal Institute of Technology)
CH-8092 Zurich, Switzerland



Sat, 25 May 1996 05:10:47 GMT  
 Symbol file problem ?
:  If this is correct, than I
: >suggest there should be a compiler switch which would allow
: >a new  symbol file to be generated using the key of an
: >existing symbol file.

: This would not help you. If there are differences in the symbol file, some
: things will not be compatible (e.g. a variable may be at a different offset,
: so you access the wrong variable, or the procedures may be in a different
: order, so you call the wrong procedure, or a record may not have the correct
: size, so you overwrite memory that has not been correctly allocated).

Hmmm. I can see that I overlooked some important details
about the design of a module such as the Display module in
the module hierarchy under Oberon. I incorrectly expected
dynamic linking to be able to resolve reordered procedures
much as a classic link editor would.

Is there an empty implementation ( with the appropriate procedure
and  record definitions ) available for the Display module
for Dos386 Oberon ?

Whitney



Sat, 25 May 1996 10:25:55 GMT  
 Symbol file problem ?

: If this is correct, than I
: suggest there should be a compiler switch which would allow
: a new  symbol file to be generated using the key of an
: existing symbol file.

: Whitney

A safer solution would probably be to follow an approach similar to
that used in MacOberon.  The symbol file key is generated by applying
some sort of hash function to the exported definition of the module.

If we assume that it is possible to order the definition (exports) in
some uniform way before applying the hash function, the symbol key will
only change if there is truly some change in the definition of the module.

Michael Franz posted here a while ago about this technique.  If you
are interested, you should contact him for the arcticle reference.

Johan
--



Mon, 27 May 1996 16:51:00 GMT  
 
 [ 4 post ] 

 Relevant Pages 

1. Change symbol factory activex for standard symbol factory v1 or v2

2. make-symbol defiencies (how make a direct symbol?)

3. How to get symbol-value from symbol-name

4. Duplicate symbols in all map files?

5. cr/lf symbol to ASCII File ???

6. Topic.Templates - Filling Multi-Valued Symbol From Text File

7. Looking for a routine to filter non-printable and symbol characters from a text file

8. Symbol files in Oberon for Linux

9. Symbol File Formats (as promised)

10. Compiling to a block symbol file from Altera Quartus

11. masm symbol files

12. Symbol table information from GNAT compiled files

 

 
Powered by phpBB® Forum Software