[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALCETrU2JMsanD__Re+18htJX07paaNBmryej_MigvXqnYbNjA@mail.gmail.com>
Date: Tue, 17 Jun 2014 21:22:34 -0700
From: Andy Lutomirski <luto@...capital.net>
To: "H. Peter Anvin" <hpa@...or.com>
Cc: Josh Boyer <jwboyer@...oraproject.org>,
"Linux-Kernel@...r. Kernel. Org" <linux-kernel@...r.kernel.org>
Subject: Re: vdso_install target broken post-3.15
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.
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
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 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.
--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