strip command strips .debug_frame and breaks stack unwinding

[foss-for-synopsys-dwc-arc-processors]

strip command strips .debug_frame and breaks stack unwinding

[vineetgarc]

For my sporadic buildroot usage, I almost always disable strip
BR2_STRIP_NONE=y
Does that work for you !

[vineetgarc]

stack unwinding can be done with .eh_frame (more canonical) or .debug_frame (mostly used in conjunction with debugging, -g etc but has almost similar actual unwind info as .eh_frame). ARC kernel unwinding for historical reasons has been .debug_frame based. OTOH strip is supposed to remove "debug cntric" info hence .debug_frame is the causality.

[danielmentzgoogle]

I'm afraid that BR2_STRIP_NONE=y does not work for our application since we are memory constrained. We'd have to store the unnecessary debug information in NOR flash. The file module net/wireless/cfg80211.ko, for example, is 6.1M in size before stripping. By removing all debug information except for .debug_frame, I can get it down to 334K which is a significant reduction in size.

Are there any plans to update the ARC kernel unwinder and move from .debug_frame to .eh_frame? If I remember correctly, the unwinder only understands dwarf-2 while dwarf-4 is current.

[vineetgarc]

I might have some experimental patches in some pvt branch to switch to .eh_frame. Although they would need wider testing to check for any regrerssions. I can post them on mailing list and perhaps u can give them a spin - Tested-by tag would nice ;-)

[vineetgarc]

oh it seems it is non trivial (if not rocket science) and will take some time - stay tuned !

[anthony-kolesov]

Hi Daniel,

Do you debug the kernel outside or from the inside? In the first case you don't need debug info on the target side - you need them only on the debug host side - so the target will contain stripped binaries, while debug host will use unstripped. In the second case, if your system has some connectivity, you can try to load the small image from flash, then copy unstripped bins via network. Technically you don't even need to copy whole unstripped bins - .dwo files should be sufficient, although creating them is extra work.

[danielmentzgoogle]

Hi Anthony,

It's not so much about running gdb, objdump etc. on these .ko files but rather about getting proper stack traces in the printk buffer when something calls dump_stack(), panic() or WARN(). We would like to be able to see stack traces even on production units. Without the .debug_frame section, stack unwinding does not work and the stack trace ends right there.

[danielmentzgoogle]

Hi Vineet,

I'd be happy to try out your patches that switch the unwinder to .eh_frame. I briefly looked at DWARF and also found it very complicated.

[vineetgarc]

Hi @danielmentzgoogle, @cupertinomiranda

It seems .eh_frame based solution (which BTW has turned out to be really really non-trivial) won't fit the issue at hand. In .eh_frame regime, there's .rela.eh_frame section with new pc relative relos (for pointer to CIE). This needs to be handled/fixed up by loader - which is fine. However thing is if you run strip on module, the relo section is gone.

Try this on x86
$ gcc bt.c -c -fasynchronous-unwind-tables # this generates .rela.eh_frame among others
$ strip bt.o # .rela.eh_frame is gone

Took a look at strip man page and it seems there's a suggested work flow. does that help
--------->8------------
Link the executable as normal.
Copy "foo" to "foo.full"
Run "strip --strip-debug foo"
Run "objcopy --add-gnu-debuglink=foo.full foo"
--------->8------------

[vineetgarc]

oh turns out there is much elegant solution ! But u do need to disable strip from buildroot and in kernel linker scripts we drop those sections. Try thr patch i just sent you
http://lists.infradead.org/pipermail/linux-snps-arc/2016-September/001483.html

[danielmentzgoogle]

Hi @vineetgarc ,
Your patch works for us. However, I would prefer if there is some way where I can have the large .ko files with all the debug information in my build tree and the stripped down version in my buildroot target directory at the same time.
On the particular platform that I am looking at, I can't have the large .ko files on the target due to size constraints. However, I still want the large .ko files with debug information on my development workstation in order to resolve memory locations from backtraces into the corresponding lines in the C source files.

[vineetgarc]

I think buildroot does that in general, it runs strip on target executables, and retains those on build artifacts. I presume same holds for kernel modules as well. But again I'm no expert in buidlroot, @abrodkin knows better.

[vineetgarc]

@danielmentzgoogle , I see what you mean. So you don't prefer that patch as that will unconditionally strip out the debug info even for host builds.

[danielmentzgoogle]

I find it convenient to have one stripped and one un-stripped copy of all ko. files in my buildroot output directory. For example:

build/linux-4.7.3/crypto/hmac.ko (un-stripped)
target/lib/modules/4.7.3/kernel/crypto/hmac.ko (stripped)

If I do not set CONFIG_DEBUG_INFO, then the debug information is missing from both files. On the other hand, if I do specify CONFIG_DEBUG_INFO, then the larger .ko file ends up in my target directory and basically breaks my target device because the rootfs grows too big.

The top level Makefile of the kernel checks for the variable INSTALL_MOD_STRIP. If it's set, it'll strip modules before it installs them. It might be an option to change this for ARC where it would use a different strip command for .ko files.

[vineetgarc]

http://lists.infradead.org/pipermail/linux-snps-arc/2016-September/001494.html

[vineetgarc]

per feedback from Daniel - closing the issue as resolved. Patches added to my for-next for 4.9 merge !