oberon, Symbol file problem ?

Symbol file problem ?

Author	Message
whit.. #1 / 4	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

Marc Brand #2 / 4	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

whit.. #3 / 4	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

Johan de Villie #4 / 4	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

Page 1 of 1

[ 4 post ]