Message-ID: <CALCETrVU2qksHZUDA+QGba1JM81B6g=OM3WAAnXhLr+t1w8gwQ@mail.gmail.com>
Date:	Wed, 18 Jun 2014 08:12:55 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	Josh Boyer <jwboyer@...oraproject.org>
Cc:	"H. Peter Anvin" <hpa@...or.com>,
	"Linux-Kernel@...r. Kernel. Org" <linux-kernel@...r.kernel.org>
Subject: Re: vdso_install target broken post-3.15

On Wed, Jun 18, 2014 at 6:09 AM, Josh Boyer <jwboyer@...oraproject.org> wrote:
> On Wed, Jun 18, 2014 at 12:22 AM, Andy Lutomirski <luto@...capital.net> wrote:
>> On Tue, Jun 17, 2014 at 8:48 PM, H. Peter Anvin <hpa@...or.com> wrote:
>>> On 06/17/2014 08:45 PM, Andy Lutomirski wrote:
>>>> On Tue, Jun 17, 2014 at 3:54 PM, Andy Lutomirski <luto@...capital.net> wrote:
>>>>> Just a heads up: gdb can't debug the vdso on 3.16-rc1.  I filed a bug:
>>>>>
>>>>> https://sourceware.org/bugzilla/show_bug.cgi?id=17064
>>>>>
>>>>> We may need to extend the fake section header hack to all vdso
>>>>> versions and stick the ELF notes in there.
>>>>
>>>> I have a semi-working implementation of a workaround, bit it adds a
>>>> fair amount of extra crud to the image, and it's pushing my
>>>> configuration past a page boundary.  I suspect that, if we're willing
>>>> to abuse the ELF format a bit more, I can get the overhead down,
>>>> though.
>>>>
>>>> Are we okay with regressing here until binutils gets fixed?
>>>>
>>>
>>> Probably not... although I guess it depends just how bad it really is.
>>
>> AFAICT the only issue is that gdb will fail to find installed debug
>> info on systems that install it into .build-id, which AFAIK means
>> Fedora and similar users who install kernel RPMs.  This won't effect
>> anyone who installs their own kernel, since it never worked correctly
>> for those users anyway.
>
> For some reason I thought SLES/OpenSUSE did build-id as well.
>

Could be.  I'm pretty sure that Debian and such don't reliably use it,
which is major reason why I dislike them.

>> Fortunately, Fedora ought to be able to update its gdb and/or binutils
>> rpm by the time that 3.16 kernel RPMs show up.  Josh, is this
>> workable?  In my experience, I've never had a sourceware.org bug
>
> Getting binutils fixed in rawhide typically isn't a problem if the
> reporter and upstream are persistent.  Getting it fixed in a more
> stable Fedora release is a bit more work and really depends on how
> invasive the fix is.
>
>> fixed, but I have had bugzilla.redhat.org bugs fixed.  I'm looking at
>> the binutils code, and I'm kind of scared of it.  Also, I don't have
>> an FSF copyright assignment on file.
>>
>> I filed this Fedora bug:
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=1110598
>>
>> Let's see what happens.  Can we give this a little while?
>
> I think that really depends on who all is using build-id for their
> debuginfo stuff and how much upstream cares about breaking them.  Even
> if it's contained to Fedora derived distros, getting binutils fixed in
> RHEL for this is much harder.  I have no idea how SLES/OpenSUSE would
> contain this if they are using build-id.

Would this be needed in RHEL-like things?

The actual breakage isn't that bad: gdb will be unable to reliably
breakpoint in the __vdso and it may also be unable to reliably
backtrace from the vdso.  In limited testing, it could unwind the
backtrace just fine, presumably using frame pointers, but it didn't
show the vdso function in the backtrace.  (glibc ought to be able to
unwind the vdso just fine -- I haven't tested it, but I can't imagine
glibc parsing section headers just for unwind unfo.)  Since there's no
support right now for build-id links in home-built kernels, 3.16 and
newer distro kernels will behave just like home-built kernels.  (If
there are non-kernel-RPM build-id users, it would be a very different
story, but I don't think that such users exist.)

But RHEL doesn't update to new major kernel releases, right?  So it
won't be affected until RHEL 8, at which point there ought to be a new
gdb.  Oracle will be affected, but unless they actually complain or
depend on this kind of gdb support, I don't know whether this matters
much.

>
>> I wrote this:
>>
>> https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/log/?h=x86/vdso_sections
>>
>> but it's bad: I'm not allocating space properly, so it doesn't
>> reliably build.  Also, it wastes space, and I'd rather just get rid of
>> this crap.
>
> The "if/when binutils gets fixed" is really the crux of the issue.
> Unless the upstream kernel puts a hard requirement on a fixed binutils
> version, we can't really depend on people having a fixed binutils.  If
> that code were to get added, it would like stay for a very long time.

The RHBZ bug is already getting some attention.

My inclination is to give this at least a week or two and then, if it
looks like binutils won't get fixed, to clean up and submit my
workaround.

Note that my workaround also causes 'file' and 'readelf -n' to work
correctly on the stripped images, but that shouldn't matter for anyone
except people who manually generate on-disk stripped images
specifically for testing file and readelf, so this seems unimportant.

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists