Mostly this is for a development context. Transportable core files are also very useful in that situation. There might be many different internal versions of an app in use at a large site, and needing to match the core file up with the right binary is still a problem.
We have customers who ship stripped -g versions of binaries so that they can match core files up with the unstripped version when the core file is given back to support. For now, I can't see why any customer would ship debug information in the binary, since there is no way of making use of that information. If the debug info could come back bundled with the core file, I think Sun could sell that feature very strongly as an "observability" and "servicability" feature. (What I have said so far is appropriate for a public discussion, but I wouldn't want to name specific customers or dig into business strategy in more detail unless we do that offline.) --chris Adam Leventhal wrote: > Hi Chris, > > Are you seeing vendors deploying applications with stabs and dwarf? Or > do you see this as necessary in development as well. > > Adam > > On Mon, Oct 17, 2005 at 12:38:27PM -0700, Chris Quenelle wrote: > >>Adding full segment data is an important improvement, >>but that misses some obvious data that you want. Section >>information (not in a loadable segment) is also important. >>The new coreadm allows the user to add the "ctf" and "symtab" >>non-loadable sections, but not stabs or dwarf information. >>This is a pretty serious omission for observability, since >>there are a fair number of customers who want source-level >>stack dumps and debugging, as well as C++ support. >> >>--chris >> >> >>Adam Leventhal wrote: >> >>>On Sun, Oct 16, 2005 at 10:46:20PM -0700, Rod Evans wrote: >>> >>> >>>>I (and the debugging folks) have come across a number of applications >>>>who try and print stack traces on a fatal error, and then prevent any >>>>core from being produced at all. Historic issues like the core being >>>>too large to leave in the cwd, or the core not being debuggable in >>>>different system environments, have now changed. coreadm(1) exists, and >>>>core files can contain every segment of the original image. >>> >>> >>>With coreadm(1M, you can, indeed, include data from whatever segments >>>you want in the core file -- including the read-only data will get you >>>the .dynsym section. You can also include the .symtab section, but, >>>unlike text, is not included by default. >>> >>>Adam >>> > >
