Re: [SH][PATCH] Disable ABI frame sniffer

[Andrew STUBBS <andrew.stubbs@st.com>]

Daniel Jacobowitz wrote:
> I was complaning about the "ABI" part.  If you want to talk about what
> kind of object it is, it's an unwinder, not a sniffer; sniffers are
> used to select unwinders.

Hmm, confusing. Well, I can change the name easily enough. It is the 
unwinder based on the ABI though. How come the unwind function is called 
sniffer?

>>Naturally you can't unwind ASM or anything without CFI without the 
>>fallback unwinder. That's why it is there. That doesn't mean it isn't 
>>irritating when it trys to unwind frames that aren't there. Most of the 
>>time you just don't need it.
> 
> 
> Quite on the contrary, my experience is that in most programs you'll
> need it at least a couple of times, e.g. to get out of bits of libc or
> linker-generated code.

Bare-machine (or OS21) sh-elf doesn't use glibc with all its 
complications. We use newlib and we always compile it with debug info 
and CFI so there is it should never need to fall back.

>>It may be possible to improve the unwinder. However, it is dependent on 
>>the values in registers and in memory. It would be impossible to prevent 
>>it getting occasionally confused.
> 
> 
> Just like the rest of GDB on both counts.

Maybe other bits of GDB need an option to switch them off when they turn 
problematic. Maybe they already do. In fact, maybe I should make this 
feature more generic and change the error message so that it says 'if 
this isn't a real problem try switching ... off'.

>>I much prefer the option to say 'My program has CFI, I know it does, I 
>>put it there, so stop trying to confuse yourself'.
> 
> 
> For any frame with CFI, the CFI is used in preference.  If you don't
> want the fallback unwinder to come into play, if as you claim you
> really don't need it, then find out why it's being triggered in the
> first place.

The problem only occurs in threads (unless 'set backtrace pastmain' is 
set, in which case it happens in any program) when the backtrace falls 
off the end of the program. There are no more frames because there's no 
more stack, but there's no way to know that unless you assume the CFI 
and program run out at the same time.

>>As to the SH maintainers, there are none listed in MAINTAINERS.
> 
> 
> Yes, my mistake; there used to be.

BTW, were you (and others) waiting for them to do something about the SH 
specific patches I have been sending? I ask because I have had no 
response on a few.

I'm currently in the process of trying to patch GDB HEAD sufficiently to 
run OS21 threaded programs on ST targets like I do with our 6.3 based 
tools. When I've got that done I'll have a better idea whether anything 
needs to be done any more. I suspect we will still _like_ to.

Thanks

Andrew Stubbs