[Bug symtab/17064] New: gdb's can't find Linux 3.16-rc1's vdso build-id

[Bug symtab/17064] New: gdb's can't find Linux 3.16-rc1's vdso build-id

[luto at mit dot edu]

https://sourceware.org/bugzilla/show_bug.cgi?id=17064

            Bug ID: 17064
           Summary: gdb's can't find Linux 3.16-rc1's vdso build-id
           Product: gdb
           Version: unknown
            Status: NEW
          Severity: normal
          Priority: P2
         Component: symtab
          Assignee: unassigned at sourceware dot org
          Reporter: luto at mit dot edu

In Linux 3.16-rc1, the vdso is more heavily stripped than it is in prior
versions.  It has no section table*.  Nonetheless, gdb should still be able to
find its build-id, because its PT_NOTE phdr is in perfect order.  eu-readelf -n
works, but readelf -n does not.

(Actually, there's a complication: due to a workaround for a bug in Go, the
64-bit vdso currently has a fake section header that does not contain a note
section.  This causes even elfutils to be unable to find the ELF notes.  If
necessary, I can change that.)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug symtab/17064] gdb's can't find Linux 3.16-rc1's vdso build-id

[luto at mit dot edu]

https://sourceware.org/bugzilla/show_bug.cgi?id=17064

--- Comment #1 from Andy Lutomirski <luto at mit dot edu> ---
I think the bug is in bfd_elf_bfd_from_remote_memory, which isn't even trying
to load phdrs when section headers are unavailable.  The binutils phdr parser
knows how to read PT_NOTE.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug symtab/17064] gdb's can't find Linux 3.16-rc1's vdso build-id

[nickc at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=17064

Nick Clifton <nickc at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |nickc at redhat dot com

--- Comment #2 from Nick Clifton <nickc at redhat dot com> ---
Hi Andy,

  Could you upload a copy of the stipped binary for us to play with ?  32-bit
and 64-bit versions if possible.

Cheers
  Nick

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug symtab/17064] gdb's can't find Linux 3.16-rc1's vdso build-id

[palves at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=17064

Pedro Alves <palves at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |palves at redhat dot com

--- Comment #3 from Pedro Alves <palves at redhat dot com> ---
Which GDB version?

Note bfd_elf_bfd_from_remote_memory was changed recently to better handle the
vDSO.  E.g., 5979d6b69b20a8355ea94b75fad97415fce4788c.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug symtab/17064] gdb's can't find Linux 3.16-rc1's vdso build-id

[luto at mit dot edu]

https://sourceware.org/bugzilla/show_bug.cgi?id=17064

--- Comment #4 from Andy Lutomirski <luto at mit dot edu> ---
Created attachment 7642
  --> https://sourceware.org/bugzilla/attachment.cgi?id=7642&action=edit
Stripped vDSO image

This is the 64-bit image mapped into memory for whatever config I'm running on
revision e0bf7b86dace87eccdabdd66d2769ccad19cb81c of the tip/x86/vdso tree.  It
should be more or less identical to Linus' tree, assuming he's fully caught up.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug symtab/17064] gdb's can't find Linux 3.16-rc1's vdso build-id

[luto at mit dot edu]

https://sourceware.org/bugzilla/show_bug.cgi?id=17064

--- Comment #5 from Andy Lutomirski <luto at mit dot edu> ---
Created attachment 7643
  --> https://sourceware.org/bugzilla/attachment.cgi?id=7643&action=edit
32-bit stripped vDSO image

32-bit variant.  This one has no sections at all, because the Go workaround
isn't needed for 32-bit code (I think).

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug symtab/17064] gdb's can't find Linux 3.16-rc1's vdso build-id

[palves at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=17064

--- Comment #6 from Pedro Alves <palves at redhat dot com> ---
GDB version?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug symtab/17064] gdb's can't find Linux 3.16-rc1's vdso build-id

[luto at mit dot edu]

https://sourceware.org/bugzilla/show_bug.cgi?id=17064

--- Comment #7 from Andy Lutomirski <luto at mit dot edu> ---
I tested GDB version 7.7.1-13.fc20.

GDB/binutils revision 5979d6b69b20a8355ea94b75fad97415fce4788c is unlikely to
help.  It's actually related to why I changed the vdso in the first place.

The issue is that there's now user/kernel shared data right after the vdso
PT_LOAD segment.  That breaks if the section headers spill past the end of the
last page in the vdso PT_LOAD segment.  It's also nice to keep the vdso mapping
as small as possible.  My solution was to just strip off the section headers
entirely.

If necessary, I'm willing to compromise in the kernel (I already had to for
Go), but it looked like this should be easy to fix in binutils.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug symtab/17064] gdb's can't find Linux 3.16-rc1's vdso build-id

[palves at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=17064

--- Comment #8 from Pedro Alves <palves at redhat dot com> ---
"unlikely to help" != "I tested current mainline and it doesn't help". ;-)  

> It's actually related to why I changed the vdso in the first place.

How so?

> My solution was to just strip off the section headers entirely.

This will break btrace disassembly again:

  https://sourceware.org/ml/gdb-patches/2014-04/msg00055.html

GDB could be fixed to not rely on section headers, but, that wouldn't look like
7.8 material, which has just branched...

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug symtab/17064] gdb's can't find Linux 3.16-rc1's vdso build-id

[luto at mit dot edu]

https://sourceware.org/bugzilla/show_bug.cgi?id=17064

--- Comment #9 from Andy Lutomirski <luto at mit dot edu> ---
(In reply to Pedro Alves from comment #8)
> "unlikely to help" != "I tested current mainline and it doesn't help". ;-)  

True.  But I'm on an amazingly slow connection, so I probably won't be able to
build and test gdb today.

> 
> > It's actually related to why I changed the vdso in the first place.
> 
> How so?

The section headers dangling off the last loadable page were a problem for the
vdso implementation as well as for gdb, so I wanted to get rid of them.

> 
> > My solution was to just strip off the section headers entirely.
> 
> This will break btrace disassembly again:
> 
>   https://sourceware.org/ml/gdb-patches/2014-04/msg00055.html
> 
> GDB could be fixed to not rely on section headers, but, that wouldn't look
> like 7.8 material, which has just branched...

Yuck.

How accurate do the section headers need to be?  Will having section headers
that don't match between the in-memory vdso and the symbol file be a problem?

IOW, if I give a section for the entire loadable segment, a dummy shstrndx
section (maybe actually aliased to another section to save space), a note
section, and a SHT_SYNDYM section (for Go), will gdb work?  Will it lose
functionality like CFI data when it loads the symbol file if the in-memory
sections don't match quite right?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug symtab/17064] gdb's can't find Linux 3.16-rc1's vdso build-id

[palves at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=17064

Pedro Alves <palves at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |markus.t.metzger at intel dot com

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug symtab/17064] gdb's can't find Linux 3.16-rc1's vdso build-id

[luto at mit dot edu]

https://sourceware.org/bugzilla/show_bug.cgi?id=17064

--- Comment #10 from Andy Lutomirski <luto at mit dot edu> ---
Apparently even stripping the names off of the sections breaks gdb.  This stuff
seems really fragile.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug symtab/17064] gdb's can't find Linux 3.16-rc1's vdso build-id

[nickc at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=17064

--- Comment #11 from Nick Clifton <nickc at redhat dot com> ---
Created attachment 7644
  --> https://sourceware.org/bugzilla/attachment.cgi?id=7644&action=edit
process note segments when no note sections are found

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug symtab/17064] gdb's can't find Linux 3.16-rc1's vdso build-id

[nickc at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=17064

--- Comment #12 from Nick Clifton <nickc at redhat dot com> ---
Hi Andy,

  Fixing "readelf -n" is fairly easy - the uploaded patch takes care of this.

Cheers
  Nick

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug symtab/17064] gdb's can't find Linux 3.16-rc1's vdso build-id

[luto at mit dot edu]

https://sourceware.org/bugzilla/show_bug.cgi?id=17064

--- Comment #13 from Andy Lutomirski <luto at mit dot edu> ---
It looks like gdb has a lot of trouble using debug symbols for DSOs that are
heavily stripped: it tries to line up addresses by section name.  I don't know
whether symbols for section-table-less DSOs are expected to work at all.

I sent these kernel patches:

http://lkml.kernel.org/g/cover.1403129369.git.luto@amacapital.net

The re-add a lot of bloat, making the vdso be two pages again, but they seem to
restore gdb's ability to debug it.

If gdb gains the ability to debug fully-stripped DSOs at some point, then maybe
I can revert those patches.

-- 
You are receiving this mail because:
You are on the CC list for the bug.