pcg@aber-cs.UUCP (Piercarlo Grandi) (02/22/90)
In article <MEISSNER.90Feb19125329@curley.osf.org> meissner@osf.org (Michael Meissner) writes:
When I worked at Data General, I maintained that the "C" in COFF meant
crippled, and not common, mostly because of the limitations of the
debug format.
We have already discussed some of this in the G++ groups, because the problem
is much worse for it. I think that, waiting for ELF, COFF can still be
used if oen is prepared to do a hack similar to that used for the AOUT
format. In AOUT the debugging information is emitted as simple strings, and
the native AOUT debug format is practically bypassed.
In COFF you could easily (very easily) use a section to hold debug
tables in whatever format. This section could be something like the .comment
section that is already customary with COFF executables (and that often
munches up a lot of space in them -- use 'mcs -d' as well as 'strip' ...).
I actually feel that using the .comment section would be fine.
Any volunteers? E.g. from vendors like DELL that sell System V based
systems...
--
Piercarlo "Peter" Grandi | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth | UUCP: ...!mcvax!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.ukmeissner@osf.org (02/23/90)
| From: pcg@aber-cs.UUCP (Piercarlo Grandi) | Newsgroups: gnu.gdb.bug | Summary: You could put extra COFF debug information in a section... | Date: 22 Feb 90 14:53:33 GMT | Reply-To: pcg@cs.aber.ac.uk (Piercarlo Grandi) | Distribution: gnu | Organization: Dept of CS, UCW Aberystwyth | (Disclaimer: my statements are purely personal) | | In article <MEISSNER.90Feb19125329@curley.osf.org> meissner@osf.org (Michael Meissner) writes: | | When I worked at Data General, I maintained that the "C" in COFF meant | crippled, and not common, mostly because of the limitations of the | debug format. | | We have already discussed some of this in the G++ groups, because the problem | is much worse for it. I think that, waiting for ELF, COFF can still be | used if oen is prepared to do a hack similar to that used for the AOUT | format. In AOUT the debugging information is emitted as simple strings, and | the native AOUT debug format is practically bypassed. (Un)forturnately, ELF does not define a standard debug format. The people at Data General who looked into it, could not find anything in the specs about it (they finally had to resort to reading the code for the SDB rewrite in C++). Evidently, it was felt that the debug format was a private choice that the compiler and debugger made. 88Open and possibly other vendors looking at going to System V.4 also made the same choice. As much as I detest the COFF debug format, I believe that a standardized debug format is useful, in that it allows you to intermix compiler A with debugger B. | In COFF you could easily (very easily) use a section to hold debug | tables in whatever format. This section could be something like the .comment | section that is already customary with COFF executables (and that often | munches up a lot of space in them -- use 'mcs -d' as well as 'strip' ...). | I actually feel that using the .comment section would be fine. On System V systems, .comment is not a good idea, since #ident strings go in there, and a debugger might find it hard to distinguish where the ident strings end for a module, and other modules debug info. Note that on a Decstation, which uses the MIPS 1.31 compiler tools, the assembler gives you no way using other sections except for the default .text/.data/.sdata/.rdata/.sbss/.bss sections. I have toyed with doing this for GCC on the Decstation.
kingdon@AI.MIT.EDU (Jim Kingdon) (02/24/90)
As much as I detest the COFF debug format, I believe that a
standardized debug format is useful
Well, let me point out that GNU has a standardized debug format: BSD
a.out executables with dbx symbols. While we have agreed in some
cases (e.g. GDB) to merge COFF support into GNU software, COFF support
isn't important to us and we put little effort into maintaining it.
On systems with COFF kernels, you can use BSD executables with COFF
encapsulation.
Some hybrid which uses COFF, but with debug tables in a separate
section or some such, might be possible. The advantage would be you
can use the system binutils and assembler. But if you port (if not
done already) GNU binutils and assembler to your machine, then you
have source to the utilities, can fix them if broken, and also get
whatever level of support is provided by the FSF and whoever else is
using the GNU utilities.
So getting encapsulation working might involve some work such as
porting the GNU utilities (should be easy except the assembler, which
shouldn't be terrible), but on the other hand, getting COFF support in
GDB working well (and/or maintaining it as GDB and/or COFF evolve) is
also work.
I will admit that dbx symbols could be better documented. dbxread.c
in GDB and dbxout.c in GCC are (as source code goes anyway) reasonably
legible, however.
Object file and debug formats have both political and technical
aspects. I think GNU/BSD format beats COFF on both.mark@Jhereg.Minnetech.MN.ORG (Mark H. Colburn) (02/28/90)
In article <9002240839.AA21345@pogo> kingdon@AI.MIT.EDU (Jim Kingdon) writes: >Well, let me point out that GNU has a standardized debug format: BSD >a.out executables with dbx symbols. While we have agreed in some >cases (e.g. GDB) to merge COFF support into GNU software, COFF support >isn't important to us and we put little effort into maintaining it. >On systems with COFF kernels, you can use BSD executables with COFF >encapsulation. > >Object file and debug formats have both political and technical >aspects. I think GNU/BSD format beats COFF on both. I wonder if anyone at FSF has seen the specification for ELF, the new loader format that is going to be used by AT&T and others. This new format seems to cure a number of the problems associate with COFF. The problem is that BSD is becoming a rarer beast, what with CSRG slowly backing out of the arena and the formation of UI and OSF. The problem that I see with using the ecapsulation method is that soon, a majority of the machines will have to encapsulate their object files. This would be unwieldy, inefficient and moderately annoying. For the time being the solution is fine, however as time marches on it may become more and more of a pain. -- Mark H. Colburn If you don't make money off of it, Open Systems Architects, Inc. it had better be either a religious mark@Minnetech.MN.ORG experience or a hobby. - Lance Cooper
ham@Neon.Stanford.EDU (Peter R. Ham) (03/01/90)
Have you seen the specification of ELF? What's it like? Is any documentation of it publicly available? Are there any shipping systems using it that one could borrow the documentation from? Peter -- Peter Ham PO Box 3430 (h)(415) 322-4390 MS Computer Science Student Stanford, CA ham@cs.stanford.edu Stanford University 94309 (o)(415) 723-2067
rms@AI.MIT.EDU (03/01/90)
The BSD object file format has some deficiencies, so we're considering switching to another format for the GNU system. However, one aspect that we are not considering changing is the debugger information. That is not where the problems are, and leaving it alone would save lots of work. So ELF won't be a good candidate. This being so, the question is whether we care enough about the systems that do use ELF to spend any time on them. Support for UNIX systems is a secondary matter for us when it involves things that will not be useful in the GNU system. It really doesn't interest us much what commercial companies are going to do. But we will be willing to add support to GCC and GDB such as we now have for COFF, provided other people write the code and maintain it.
rfg@ics.uci.edu (Ronald Guilmette) (03/01/90)
In article <9002281958.AA07987@sugar-bombs.ai.mit.edu> rms@AI.MIT.EDU writes: >The BSD object file format has some deficiencies, so we're considering >switching to another format for the GNU system. However, one aspect that >we are not considering changing is the debugger information. That is not >where the problems are, and leaving it alone would save lots of work. >So ELF won't be a good candidate. > >This being so, the question is whether we care enough about the >systems that do use ELF to spend any time on them. Support for UNIX >systems is a secondary matter for us when it involves things that will >not be useful in the GNU system. It really doesn't interest us much >what commercial companies are going to do. Mike Meissner has stated a couple of times that ELF does *not* include any specification about debugging information. He says that part is left up to individual implementors. So it would seem to be theoretically possible to use ELF *with* the GNU-style debugging information. Of course, if ELF has other problems which a GNU format could solve, then using ELF at all may be more trouble that it is worth. Then again, there is *some* advantage in *sharing* standards (rather than trying to create your own). It is obviously not an advantage that should override all other factors, but it should be weighed in the balance along with other important critera. // Ron Guilmette (rfg@ics.uci.edu) // C++ Entomologist // Motto: If it sticks, force it. If it breaks, it needed replacing anyway.
ham@Neon.Stanford.EDU (Peter R. Ham) (03/01/90)
While we are on the subject of object files? Has anyone actually done any research or written any papers on this? I still can't find an information on elf. I know coff and bsd. I like coff section and I like stabs debugging information. Any other formats of interest? Peter -- Peter Ham PO Box 3430 (h)(415) 322-4390 MS Computer Science Student Stanford, CA ham@cs.stanford.edu Stanford University 94309 (o)(415) 723-2067
meissner@osf.org (03/02/90)
| From: rms@AI.MIT.EDU | Newsgroups: gnu.gdb.bug | Date: 28 Feb 90 19:58:15 GMT | Distribution: gnu | Organization: GNUs Not Usenet | | The BSD object file format has some deficiencies, so we're considering | switching to another format for the GNU system. However, one aspect that | we are not considering changing is the debugger information. That is not | where the problems are, and leaving it alone would save lots of work. | So ELF won't be a good candidate. I don't know about the lack of problems with the BSD debug format. Yes COFF is certainly crippled, but current stabs are only marginly better. The problem is that both formats are living back in the mid 70's when UNIX compilers did little optimization (other than peephole optimizations). Some of the problems that I have with either format (though they can be solved with extensions, and such): 1) No support for variable lifetime information except on block boundaries. GCC will allocate multiple values to the same registers if their lifetimes are disjoint. This means that the user gets confused if s/he wants to look at a variable after the compiler has already put another value into the register. On machines that pass arguments in registers, if the argument is used once, and not used again, this will mean that the function traceback will print bogus values. 2) No support for variables living in multiple places (such as normally on the stack, but in a register within a loop). I know that GCC currently does not do this optimization, but I would hope that is only a temporary restriction. 3) No support for multiple statements on one line. This is particularly bad for 'for' statements, which have three implicit statements, but if it's all on one line, you can only set a breakpoint on the initial condition, and not on the test (or increment) statement. 4) No support for keeping line numbers during code motion. If a divide, say, is moved out of a loop, there is no line number associated with that code. 5) Debuggable code must have a frame pointer. Of the RISC machines I familar with (MIPS and M88K), the native compilers routinely eliminate the frame pointer, and have extra tables to describe how to get the virtual frame pointer from the stack pointer, and where saved registers live.