"Brent Dax" <[EMAIL PROTECTED]> writes: [...]
> # This can be implemented in 2 ways: > # - Create our own debugging format > # - Use an already existing one > # The first way might be more fun, but I think the second one > # would be better. IMHO we should use DWARF-2. The Mono Project > # does something similar. > > Can you justify these? Creating our own one is reinventing the wheel. You should not do that if you don't have a good reason for this. Until now I've no reason not to use a standard debugging format. > Parrot may want to support file names in different character sets, > which I doubt much of anything else handles correctly. Ok, this is a reason. But is this really a problem? Parrot may also want to open files in diffrent character sets, but somehow it has to pass the filename to the operation system. This call takes a plain c-string. Only that this NUL-terminated string will be stored in the debug section. You might say that will be depending on the default character set of the machine creating the debugging, but we can store this information and if neccessary transcode. The bytecodeformat already transcodes big/little endian. > And if we choose to use an existing format, why DWARF-2? I don't know very much debugging formats. All I know about debugging formats is from the gdb manual (and the dwarf-spec). - stabs: One of the first debugging formats. But it feels like a hack getting around some limits in the underlying file format. - COFF: (quoting gdb-manual): "The basic COFF definition includes debugging information. The level of support is minimal and non-extensible, and is not often used." - DWARF-1: The debug format of the ELF file format, designed to be extendible and language independent, but superseeded by an incompatible second version - DWARF-2: The current version of this debugging format. - DWARF-3: The next generation, but as far as I can see at least in the line number information compatible to DWARF-2. Mips and SOM I don't have looked at. So the reasons for DWARF-2 were: Its standardized, documented, language independent, and I've already used it once. Ok the last reason is not valid for a design decision. Bye b. -- Juergen Boemmels [EMAIL PROTECTED] Fachbereich Physik Tel: ++49-(0)631-205-2817 Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906 PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
