Re: Should strip discard the .ctf section ?

["Maciej W. Rozycki" <macro at wdc dot com>]

On Tue, 8 Oct 2019, Alan Modra wrote:

> > In any case, let's see how many bug reports we get about .ctf remaining in 
> > final objects, we can always reconsider.
> 
> I'm with Michael and Nick on this.  If for no other reason than the
> people doing all the work implementing a large feature like this
> should get a lot more say than armchair critics.  (And yes, I count
> myself just an armchair critic regarding this issue.)

 FWIW we have a precedent here in that MIPS `.pdr' sections are also left 
alone by `strip' by default under the assumption this will let frame 
unwinding work (although regrettably we've never got it right in GDB, 
before dropping support for it altogether many years ago); and likewise 
there is an option for the toolchain not to produce them in the first 
place.

 So if the presence of `.ctf' sections in system libraries will let people 
do frame unwinding in their own software being debugged without a need to 
chase debug information for the system stuff, such as libc, which may not 
be readily available or at all, then IMO this will be a *huge* improvement 
in functionality.  And a strong argument in favour to `strip' keeping 
`.ctf' sections by default.

 For the unaware: MIPS `.pdr' or Procedure Description Record sections 
hold per-function register usage information, which is supposed to be 
enough for a debugger to recreate the frame layout and hence unwind it.  
This is essentially a reduced variant of full ECOFF debug information that 
for historical reasons the MIPS target support being also embedded into 
ELF files.

 Finally, why is the ability to unwind frames for system stuff so 
important in debugging user software?

 Well, if a program is interrupted within a system shared libarary, which 
could be due to various reasons, such as the user having set a watchpoint 
that triggered or interrupting a syscall, and either the current frame or 
any of the upper ones cannot be unwound, then the user is essentially lost 
in the program being debugged.  This is because they are unable to figure 
out where the current place has been called from in their program and they 
have their ability to debug the program limited to accessing global 
variables and machine instruction stepping only.

 The psABIs for some architectures such as Power and x86 define the stack 
frame layout in a fixed manner, which lets frame unwinding work even in 
the absence of any frame information associated with the binary files 
being debugged, but many psABIs do not and people get lost.

  Maciej