home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / gnu / misc / discuss / 4662 < prev    next >
Encoding:
Internet Message Format  |  1993-01-27  |  3.3 KB
  1. Xref: sparky gnu.misc.discuss:4662 comp.sys.hp:15345
  2. Path: sparky!uunet!uunet.ca!canrem!telly!utzoo!torn!cs.utexas.edu!sdd.hp.com!saimiri.primate.wisc.edu!ames!agate!forney.berkeley.edu!jbuck
  3. From: jbuck@forney.berkeley.edu (Joe Buck)
  4. Newsgroups: gnu.misc.discuss,comp.sys.hp
  5. Subject: Re: HP debug info and the FSF (was: Attaching gdb to a running process on an HP)
  6. Date: 27 Jan 1993 20:29:36 GMT
  7. Organization: U. C. Berkeley
  8. Lines: 57
  9. Message-ID: <1k6rbg$caq@agate.berkeley.edu>
  10. References: <1993Jan24.205213.14915@bmerh85.bnr.ca> <HUTTAR.93Jan25164454@hp750.itg.ti.com> <FRANL.93Jan27115049@draco.centerline.com>
  11. NNTP-Posting-Host: forney.berkeley.edu
  12.  
  13. In article <FRANL.93Jan27115049@draco.centerline.com> franl@centerline.com (Fran Litterio) writes:
  14. >> Yes, you can get a modified gcc-2.3.3.u3 for PA HP's from
  15. >> jaugar.utah.edu:/dist.
  16. >> I just downloaded hpuxbin.tar.Z, which contained the executables
  17. >> for gcc, gdb, etc. that worked (with symbolic debugging & all)
  18. >> without modification.
  19. >
  20. >I thought that HP was refusing to "free" its debugger symbol table
  21. >format (specifically the header file that defines all of the debugger
  22. >symbol data structures).  That would mean no Gnu product can read or
  23. >write HP debug info, because the FSF won't use code that isn't free,
  24.  
  25. This is correct.  The tools from jaguar (not jaugar, as above) generate
  26. debug information using "stabs" format.  This means that gcc/g++ code
  27. can be debugged with gdb, but you can't use gdb to debug code produced
  28. by HP's compilers, and you can't use HP's debugger to debug gcc/g++
  29. code.
  30.  
  31. >Which is it: Do gcc and gdb understand HP debug info or don't they?
  32.  
  33. They don't -- they use an incompatible format, the same format used
  34. on BSDish systems.
  35.  
  36. >I too have heard about work at the University of Utah to teach gcc/gdb
  37. >about HP debug info, but I have also heard that HP has effectively
  38. >killed that work by refusing to free the necessary header file.
  39.  
  40. They've killed it even deader than that.  The Utah people have signed
  41. a nondisclosure agreement, meaning they could be sued if they reveal
  42. HP trade secrets even if they found some other way to do the job
  43. (without HP proprietary headers).  Either HP will need to relent,
  44. or someone else (who has not signed a nondisclosure) will need to
  45. do the work.
  46.  
  47. I've had similar problems with HP, attempting to port a freely
  48. redistributable system to the HP.  This system does incremental linking,
  49. which is very tricky on the HP-PA architecture.  HP's attitude on things
  50. like this is not like other companies.  I could get the information,
  51. perhaps, by signing a nondisclosure (HP's rivals would simply send me
  52. the information), but that would prevent releasing free software that
  53. uses the ideas.
  54.  
  55. To be fair, my contact at HP found me some non-HP experts to talk to
  56. so I could make some progress on my problem.  I'm still bothered by
  57. the fact that it is evidently against company policy to permit me
  58. to talk to an HP employee who, say, knows how the linker works.
  59.  
  60. Given this attitude on the part of HP, I'd have to recommend that research
  61. organizations avoid the company until they have a change of policy -- it
  62. shouldn't be a secret as to how to do advanced programming on your
  63. workstation.  If it is, and you need to do this kind of programming, it
  64. might be a good idea to buy someone else's.
  65.  
  66.  
  67.  
  68. --
  69. Joe Buck    jbuck@ohm.berkeley.edu
  70.