Bug 725378

Hmm... IMO the real question is: where is the STABS data coming from to the kernel build on ppc? While it might well manage to build with older rpm versions, STABS has never been supported by debugedit and its presence causes obscure build failures on some platforms when (and likely just silent garbage on others), see bug 453506.

Still happens with kernel-3.1.0-0.rc3.git0.0.fc16 and rpm-4.9.1.1-2.fc16:
http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=279037

Asking for a comment from our kernel maintainers...

(In reply to comment #1)
> Hmm... IMO the real question is: where is the STABS data coming from to the
> kernel build on ppc? While it might well manage to build with older rpm
> versions, STABS has never been supported by debugedit and its presence causes
> obscure build failures on some platforms when (and likely just silent garbage
> on others), see bug 453506.

There are a handful of files in the powerpc kernel that have .stabs entries (mostly .S files).  They've been like that as long as I can remember.  Aside from that, I can't think of anything immediately.

Karsten, could you do a build with the -s removed from the make invocations so the CFLAGS passed can be seen?

Created attachment 520403 [details]
build log without the -s flag

Created attachment 520406 [details]
build log without the -s flag

URLs as an attachment didn't work as expected, attached the real log as the scratch-build log might get deleted and the URL woudln't work anymore.

So the powerpc kernel is built with a few .stabs entries as noted before, and with -fno-dwarf2-cfi-asm in CFLAGS (which effects dwarf unwind info, but doesn't have anything to do with stabs).  As far as I can tell, this has been like this for quite some time.  Nothing has changed in the kernel in this area, so I'm not sure why this is considered a kernel bug.

Panu, did anything in rpm 4.9.1 change in this area?

debugedit has never supported stabs, and previously stabs presence caused mysterious build failures on some architectures and produced what I presume to be garbage debuginfo on others - see bug 453506.

The only change in rpm >= 4.9.1 behavior here is that it now bails out with a hard error when .stabs is encountered.

(In reply to comment #7)
> debugedit has never supported stabs, and previously stabs presence caused
> mysterious build failures on some architectures and produced what I presume to
> be garbage debuginfo on others - see bug 453506.

Yeah, I got that from comment #1.  It's odd that it never even threw a warning about the stabs in builds using rpm < 4.9.1 though.  If it had, we might have fixed this a long time ago.
> 
> The only change in rpm >= 4.9.1 behavior here is that it now bails out with a
> hard error when .stabs is encountered.

I'm guessing we can't revert back to not failing on stabs in rpm.  Unless maybe we can have a macro to set for "ignore stabs" or something?

Otherwise that leaves two options (which aren't necessarily conflicting):

1) Disable debuginfo for ppc/ppc64 kernel builds.  This is probably the quickest option as a workaround, and debuginfo probably isn't needed all that much at the moment.

2) Patch out the stabs entries in the kernel, which have been there forever.  Arguably that isn't all that bad, as not many things use stabs and dwarf2 is better overall, but I wouldn't want to do that without the patch being clearly on its way to upstream.

It failed again:

WARNING: modpost: Found 7 section mismatch(es).
To see full details build your kernel with:
'make CONFIG_DEBUG_SECTION_MISMATCH=y'
arch/powerpc/kernel/built-in.o: In function `sys_call_table':
(.text+0x7ac8): undefined reference to `sys_nfsservctl'

http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=281090

(In reply to comment #9)
> It failed again:
> 
> WARNING: modpost: Found 7 section mismatch(es).
> To see full details build your kernel with:
> 'make CONFIG_DEBUG_SECTION_MISMATCH=y'
> arch/powerpc/kernel/built-in.o: In function `sys_call_table':
> (.text+0x7ac8): undefined reference to `sys_nfsservctl'
> 
> http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=281090

Yeah, that's a known (and fixed) upstream issue with rc4.  We have rc5 in rawhide that contains the fix.  f16 will probably get bumped to rc5 or rc6 sometime this week.  You could try a scratch build of the rawhide kernel on f16.

some minor tweaks for the filelist were required for
http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=281097
but finally I got a kernel:
http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=281101

Created attachment 522222 [details]
Allow STABS to be turned off

What about: 
3) Add a CONFIG_PPC_STABS and wrap the .stabs in #ifdef guards, it could be def_bool y so that upstream sees no change and we could just add CONFIG_PPC_STABS=n to the Fedora kernel config allowing a build and and debuginfo.

Seems like the most flexible approach to me.  If you guys agree I'll try to get it in upstream.

Hum... so the .stab entries are manually added in the kernel source code. And grepping through the kernel source, ppc is not alone in going that. In fact pretty much all architectures would appear to have them through STABS_DEBUG macro, which doesn't seem to be conditionalized anywhere, which makes me wonder why this is only hitting ppc. It also would seem that *both* dwarf and stabs are being manually added.

I was under the impression that there would only ever be one kind of debug info present (gcc does refuse to generate more than one kind of debuginfo at once, but then I had no idea folks would manually add these babies). Quite possibly debugedit needs a more subtle fix than the current sledgehammer, something like "only barf if no dwarf-info is found" or so.

Panu, assigning this back to rpm for now based on your last comment.  It would indeed be nice to use something other than a sledgehammer.  Might I suggest a framing hammer, or even a ball peen hammer?

Duh, sorry I had forgotten all about this until pknirsch kicked me (again :)

In rpm >= 4.9.1.2-3.fc17, debugedit just warns and stops further processing if it encounters STABS. This is hardly a "correct" way to fix the issue but until I get a chance to figure out something better it should pass as a workaround for this.

Gah.. should've been "warns and stops further processing but does not fail the build."

can we have an official F16 package with these fixes, please ?
Even a git commit to the f16 branch without a new package will do...