Bug 725378 - error 'Stabs debuginfo not supported: .tmp_vmlinux' during kernel-3.0 build
error 'Stabs debuginfo not supported: .tmp_vmlinux' during kernel-3.0 build
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: rpm (Show other bugs)
rawhide
powerpc Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Panu Matilainen
Fedora Extras Quality Assurance
:
Depends On:
Blocks: F16Betappc
  Show dependency treegraph
 
Reported: 2011-07-25 06:48 EDT by Karsten Hopp
Modified: 2012-03-14 09:10 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-01-13 15:05:01 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
build log without the -s flag (75 bytes, text/plain)
2011-08-29 09:59 EDT, Karsten Hopp
no flags Details
build log without the -s flag (2.68 MB, text/plain)
2011-08-29 10:03 EDT, Karsten Hopp
no flags Details
Allow STABS to be turned off (3.90 KB, patch)
2011-09-08 21:40 EDT, Tony Breeds
no flags Details | Diff

  None (edit)
Description Karsten Hopp 2011-07-25 06:48:43 EDT
Description of problem:
The 3.0 kernel doesn't build anymore with the latest rpm on Fedora-PPC with the error: 
WARNING: modpost: Found 12 section mismatch(es).
To see full details build your kernel with:
'make CONFIG_DEBUG_SECTION_MISMATCH=y'
+ /usr/lib/rpm/debugedit -b /builddir/build/BUILD -d /usr/src/debug -i .tmp_vmlinux1
Stabs debuginfo not supported: .tmp_vmlinux1
make: *** [.tmp_vmlinux1] Error 1

It builds just fine with rpm-4.9.0, though. 


Version-Release number of selected component (if applicable):
rpm-4.9.1-1.fc16

How reproducible:
always

Steps to Reproduce:
1. try to build the latest kernel with rpm-4.9.1 (on PPC, if that matters)
2.
3.
  
Actual results:
http://ppc.koji.fedoraproject.org/koji/getfile?taskID=259009&name=build.log

Additional info:
I know that rpm-4.9.1-1 has been untagged from dist-f16, but this looks like a different problem than the appended '/'
Comment 1 Panu Matilainen 2011-08-15 06:39:39 EDT
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.
Comment 2 Karsten Hopp 2011-08-25 12:55:50 EDT
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...
Comment 3 Josh Boyer 2011-08-25 13:39:24 EDT
(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?
Comment 4 Karsten Hopp 2011-08-29 09:59:31 EDT
Created attachment 520403 [details]
build log without the -s flag
Comment 5 Karsten Hopp 2011-08-29 10:03:53 EDT
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.
Comment 6 Josh Boyer 2011-09-06 10:07:04 EDT
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?
Comment 7 Panu Matilainen 2011-09-08 04:47:39 EDT
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.
Comment 8 Josh Boyer 2011-09-08 08:42:50 EDT
(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.
Comment 9 Karsten Hopp 2011-09-08 10:09:16 EDT
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
Comment 10 Josh Boyer 2011-09-08 10:18:40 EDT
(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.
Comment 11 Karsten Hopp 2011-09-08 18:09:29 EDT
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
Comment 12 Tony Breeds 2011-09-08 21:40:55 EDT
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.
Comment 13 Panu Matilainen 2011-09-09 01:27:39 EDT
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.
Comment 14 Josh Boyer 2011-09-22 06:35:29 EDT
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?
Comment 15 Panu Matilainen 2011-10-28 08:46:41 EDT
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.
Comment 16 Panu Matilainen 2011-10-28 08:47:44 EDT
Gah.. should've been "warns and stops further processing but does not fail the build."
Comment 17 Karsten Hopp 2011-12-02 11:59:32 EST
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...

Note You need to log in before you can comment on or make changes to this bug.