Rainer Orth wrote: > George Vasick writes: > >>>>> Rather than list all files and directories in SUNWgdb, it would be better >>>>> to list the exported (and imported) interfaces and their stability. >>>> exported interfaces: >>>> * CLI commands: volatile >>>> * MI commands: volatile >>> You need to list the commands explicitly, I think. And I don't think >>> volatile matches reality for GDB: while there are changes, I don't think >>> there are many (if at all) incompatible ones. Maybe Uncommitted is more >>> appropriate, but this would need to be investigated. >> OK, in this case, the exported interfaces would be: >> >> /usr/bin/gdb >> /usr/bin/gdbtui >> >> Gdb 6.3 was declared volatile. I reviewed the Interface Taxonomy >> document again. Uncommitted could probably be OK as well but we at Sun >> actually have no control over these interfaces. > > Sun control is not the point here and never was; this is a common > misunderstanding. This is all about the actual stability of the > interfaces, which is all the user cares about, not who controls them. If > the project has a track record of keeping interfaces stable, non-Sun > projects can easily be Uncommitted or even Committed.
Maybe I didn't express my concern correctly. I think James' reply gets to the root of the problem. The stability of gdb interfaces is really up to its maintainers. Our goal is simply to port it to Solaris and preserve the exported interfaces as they come from the maintainers. What if I make a stability claim that Sun cannot honor down the road? > >>>> imported interfaces: >>>> * ELF >>>> * DWARF >>>> * /proc >>>> * libdl.so.1 >>>> * libcurses.so.1 >>>> * libsocket.so.1 >>>> * libnsl.so.1 >>>> * libm.so.2 >>>> * libexpat.so.1 >>>> * libc.so.1 >>>> * libmp.so.2 >>>> * libmd.so.1 >>>> * libscf.so.1 >>>> * libuutil.so.1 >>>> * libgen.so.1 >>>> * libsmbios.so.1 >>> There are not interfaces per se: you'd rather list the corresponding ARC >>> cases (if any) and their stability. Apart from that, the list seems >>> strange as is: I won't believe gdb links to libsmbios.so.1 directly. I >>> suppose you took the ldd output, which also lists indirect dependencies >>> which are of no concern here. If I check /usr/bin/gdb on snv_121 (SPARC), >>> I find that libmp, libmd, libscf, libuutil and libgen are in that >>> category. >> Here is the pared down list taken from directly link line: >> >> libdl >> libcurses >> libsocket >> libnsl >> libm >> libexpat >> libc > > Ok, thanks. > > What about the following two questions, though? I feel these are implementation rather than architectural issues. Please advise if they should be included in this case. Thanks, George > >> Is there any reason to switch from libncurses as used in gdb 6.3 >>> to libcurses? >>> >>>> > In >>>>> particular, what about readline support? Will it be included? >>>> readline support is present. gdb 6.8 includes its own copy of >>>> readline-5.1 source which is used during the build. >>> I think this is unfortunate: since we now include libreadline.so, it would >>> be much better to use that one rather than to statically link a private >>> copy. > > Rainer > > ----------------------------------------------------------------------------- > Rainer Orth, Center for Biotechnology, Bielefeld University
