Hi,
I'm guessing commit 6f121e548f83674ab4920a4e60afb58d4f61b829 is what
broke the vdso_install target:
+ make -s ARCH=x86_64
INSTALL_MOD_PATH=/home/jwboyer/rpmbuild/BUILDROOT/kernel-3.16.0-0.rc0.git1.1.fc21.x86_64
vdso_install KERNELRELEASE=3.16.0-0.rc0.git1.1.fc21.x86_64
make[1]: *** No rule to make target `arch/x86/vdso/vdso.so.dbg',
needed by `vdso.so'. Stop.
make: *** [vdso_install] Error 2
The crazy Fedora versioning there corresponds to
3f17ea6dea8ba5668873afa54628a91aaa3fb1c0 in Linus' tree. I'll poke at
this some, but if you have some quick ideas I'd be happy to try them.
josh
On Wed, Jun 11, 2014 at 10:14 AM, Josh Boyer <[email protected]> wrote:
> Hi,
>
> I'm guessing commit 6f121e548f83674ab4920a4e60afb58d4f61b829 is what
> broke the vdso_install target:
>
> + make -s ARCH=x86_64
> INSTALL_MOD_PATH=/home/jwboyer/rpmbuild/BUILDROOT/kernel-3.16.0-0.rc0.git1.1.fc21.x86_64
> vdso_install KERNELRELEASE=3.16.0-0.rc0.git1.1.fc21.x86_64
> make[1]: *** No rule to make target `arch/x86/vdso/vdso.so.dbg',
> needed by `vdso.so'. Stop.
> make: *** [vdso_install] Error 2
>
> The crazy Fedora versioning there corresponds to
> 3f17ea6dea8ba5668873afa54628a91aaa3fb1c0 in Linus' tree. I'll poke at
> this some, but if you have some quick ideas I'd be happy to try them.
OK, I'm stumped. Looking at that commit, it removes all target
invocations for vdso.so. Which means even a simple 'make' in the vdso
directory fails with:
[jwboyer@vader vdso]$ make
make: *** No rule to make target `/vdso.so', needed by `/vdso.o'. Stop.
[jwboyer@vader vdso]$
So how was this commit build tested?
josh
On 06/11/2014 08:16 AM, Josh Boyer wrote:
> On Wed, Jun 11, 2014 at 10:14 AM, Josh Boyer <[email protected]> wrote:
>> Hi,
>>
>> I'm guessing commit 6f121e548f83674ab4920a4e60afb58d4f61b829 is what
>> broke the vdso_install target:
>>
>> + make -s ARCH=x86_64
>> INSTALL_MOD_PATH=/home/jwboyer/rpmbuild/BUILDROOT/kernel-3.16.0-0.rc0.git1.1.fc21.x86_64
>> vdso_install KERNELRELEASE=3.16.0-0.rc0.git1.1.fc21.x86_64
>> make[1]: *** No rule to make target `arch/x86/vdso/vdso.so.dbg',
>> needed by `vdso.so'. Stop.
>> make: *** [vdso_install] Error 2
>>
>> The crazy Fedora versioning there corresponds to
>> 3f17ea6dea8ba5668873afa54628a91aaa3fb1c0 in Linus' tree. I'll poke at
>> this some, but if you have some quick ideas I'd be happy to try them.
>
> OK, I'm stumped. Looking at that commit, it removes all target
> invocations for vdso.so. Which means even a simple 'make' in the vdso
> directory fails with:
>
> [jwboyer@vader vdso]$ make
> make: *** No rule to make target `/vdso.so', needed by `/vdso.o'. Stop.
> [jwboyer@vader vdso]$
>
> So how was this commit build tested?
>
Since when do we support "make" in a subdirectory?
-hpa
On Wed, Jun 11, 2014 at 11:18 AM, H. Peter Anvin <[email protected]> wrote:
> On 06/11/2014 08:16 AM, Josh Boyer wrote:
>> On Wed, Jun 11, 2014 at 10:14 AM, Josh Boyer <[email protected]> wrote:
>>> Hi,
>>>
>>> I'm guessing commit 6f121e548f83674ab4920a4e60afb58d4f61b829 is what
>>> broke the vdso_install target:
>>>
>>> + make -s ARCH=x86_64
>>> INSTALL_MOD_PATH=/home/jwboyer/rpmbuild/BUILDROOT/kernel-3.16.0-0.rc0.git1.1.fc21.x86_64
>>> vdso_install KERNELRELEASE=3.16.0-0.rc0.git1.1.fc21.x86_64
>>> make[1]: *** No rule to make target `arch/x86/vdso/vdso.so.dbg',
>>> needed by `vdso.so'. Stop.
>>> make: *** [vdso_install] Error 2
>>>
>>> The crazy Fedora versioning there corresponds to
>>> 3f17ea6dea8ba5668873afa54628a91aaa3fb1c0 in Linus' tree. I'll poke at
>>> this some, but if you have some quick ideas I'd be happy to try them.
>>
>> OK, I'm stumped. Looking at that commit, it removes all target
>> invocations for vdso.so. Which means even a simple 'make' in the vdso
>> directory fails with:
>>
>> [jwboyer@vader vdso]$ make
>> make: *** No rule to make target `/vdso.so', needed by `/vdso.o'. Stop.
>> [jwboyer@vader vdso]$
>>
>> So how was this commit build tested?
>>
>
> Since when do we support "make" in a subdirectory?
Dunno. Since when do we break existing make targets that worked fine?
Seriously, I'm just asking how this was build tested so I can try and
duplicate that and then figure out how to fix the actual bug.
josh
On Wed, Jun 11, 2014 at 8:16 AM, Josh Boyer <[email protected]> wrote:
> On Wed, Jun 11, 2014 at 10:14 AM, Josh Boyer <[email protected]> wrote:
>> Hi,
>>
>> I'm guessing commit 6f121e548f83674ab4920a4e60afb58d4f61b829 is what
>> broke the vdso_install target:
>>
>> + make -s ARCH=x86_64
>> INSTALL_MOD_PATH=/home/jwboyer/rpmbuild/BUILDROOT/kernel-3.16.0-0.rc0.git1.1.fc21.x86_64
>> vdso_install KERNELRELEASE=3.16.0-0.rc0.git1.1.fc21.x86_64
>> make[1]: *** No rule to make target `arch/x86/vdso/vdso.so.dbg',
>> needed by `vdso.so'. Stop.
>> make: *** [vdso_install] Error 2
>>
>> The crazy Fedora versioning there corresponds to
>> 3f17ea6dea8ba5668873afa54628a91aaa3fb1c0 in Linus' tree. I'll poke at
>> this some, but if you have some quick ideas I'd be happy to try them.
>
> OK, I'm stumped. Looking at that commit, it removes all target
> invocations for vdso.so. Which means even a simple 'make' in the vdso
> directory fails with:
>
> [jwboyer@vader vdso]$ make
> make: *** No rule to make target `/vdso.so', needed by `/vdso.o'. Stop.
> [jwboyer@vader vdso]$
>
> So how was this commit build tested?
>
There is no longer a vdso.so file at all, and I failed to test
vdso_install. The kernel builds and works just fine, because nothing
expects the vdso.so file to exist.
vdso_install is neat, and I've often wanted the vdso to be installed
along with modules all the time so that gdb, etc can use the .dbg
files. That being said, I clearly broke it pretty thoroughly.
Is vdso_install supposed to install a .so file or just a .so.dbg file?
I'm having trouble parsing this:
quiet_cmd_vdso_install = INSTALL $@
cmd_vdso_install = cp $(obj)/[email protected] $(MODLIB)/vdso/$@
$(vdso-install-y): %.so: $(obj)/%.so.dbg FORCE
@mkdir -p $(MODLIB)/vdso
$(call cmd,vdso_install)
This seems like a rather complicated way of saying that the .so.dbg is
installed with the .dbg at the end removed. We can do that. Let me
see if I can disentangle the makefile enough.
If we need real stripped .so files, vdso2c knows how to generate them,
but the makefile doesn't invoke it like that. I don't see why we'd
want to install them, though.
While I'm on this topic: would it be useful to also create symlinks
corresponding to the build ids?
--Andy
On Wed, Jun 11, 2014 at 8:20 AM, Josh Boyer <[email protected]> wrote:
> On Wed, Jun 11, 2014 at 11:18 AM, H. Peter Anvin <[email protected]> wrote:
>> On 06/11/2014 08:16 AM, Josh Boyer wrote:
>>> On Wed, Jun 11, 2014 at 10:14 AM, Josh Boyer <[email protected]> wrote:
>>>> Hi,
>>>>
>>>> I'm guessing commit 6f121e548f83674ab4920a4e60afb58d4f61b829 is what
>>>> broke the vdso_install target:
>>>>
>>>> + make -s ARCH=x86_64
>>>> INSTALL_MOD_PATH=/home/jwboyer/rpmbuild/BUILDROOT/kernel-3.16.0-0.rc0.git1.1.fc21.x86_64
>>>> vdso_install KERNELRELEASE=3.16.0-0.rc0.git1.1.fc21.x86_64
>>>> make[1]: *** No rule to make target `arch/x86/vdso/vdso.so.dbg',
>>>> needed by `vdso.so'. Stop.
>>>> make: *** [vdso_install] Error 2
>>>>
>>>> The crazy Fedora versioning there corresponds to
>>>> 3f17ea6dea8ba5668873afa54628a91aaa3fb1c0 in Linus' tree. I'll poke at
>>>> this some, but if you have some quick ideas I'd be happy to try them.
>>>
>>> OK, I'm stumped. Looking at that commit, it removes all target
>>> invocations for vdso.so. Which means even a simple 'make' in the vdso
>>> directory fails with:
>>>
>>> [jwboyer@vader vdso]$ make
>>> make: *** No rule to make target `/vdso.so', needed by `/vdso.o'. Stop.
>>> [jwboyer@vader vdso]$
>>>
>>> So how was this commit build tested?
>>>
>>
>> Since when do we support "make" in a subdirectory?
>
> Dunno. Since when do we break existing make targets that worked fine?
>
make in a subdirectory like that (and the vdso directory in
particular) is amazingly glitchy. I think it's lucky it used to work
like that.
> Seriously, I'm just asking how this was build tested so I can try and
> duplicate that and then figure out how to fix the actual bug.
cd ../../..; make :)
I'll race you to trying to fix it.
--Andy
On 06/11/2014 08:20 AM, Josh Boyer wrote:
>>
>> Since when do we support "make" in a subdirectory?
>
> Dunno. Since when do we break existing make targets that worked fine?
>
> Seriously, I'm just asking how this was build tested so I can try and
> duplicate that and then figure out how to fix the actual bug.
>
Just building normally, from the top level. The actual problem here is
that "make vdso_install" (unstripped vdso*.so files) doesn't work, which
is somewhat obscure (which is not to say unimportant - it isn't.)
-hpa
On 06/11/2014 08:20 AM, Andy Lutomirski wrote:
>
> Is vdso_install supposed to install a .so file or just a .so.dbg file?
> I'm having trouble parsing this:
>
> quiet_cmd_vdso_install = INSTALL $@
> cmd_vdso_install = cp $(obj)/[email protected] $(MODLIB)/vdso/$@
> $(vdso-install-y): %.so: $(obj)/%.so.dbg FORCE
> @mkdir -p $(MODLIB)/vdso
> $(call cmd,vdso_install)
>
> This seems like a rather complicated way of saying that the .so.dbg is
> installed with the .dbg at the end removed. We can do that. Let me
> see if I can disentangle the makefile enough.
>
That is, indeed, what it says.
> If we need real stripped .so files, vdso2c knows how to generate them,
> but the makefile doesn't invoke it like that. I don't see why we'd
> want to install them, though.
I don't think there is any point in that.
-hpa
This changes kbuild slightly because I didn't want to fight with using
static pattern rules and extra obfuscated fake targets just to write a
loop.
Better ideas / cleanups welcome.
Andy Lutomirski (2):
kbuild: Add recipe-cmd, an @-less cmd variant
x86,vdso: Fix vdso_install
arch/x86/vdso/Makefile | 20 +++++++-------------
scripts/Kbuild.include | 1 +
2 files changed, 8 insertions(+), 13 deletions(-)
--
1.9.3
It's awkward to put $(call cmd,xyz) in a loop in a recipe because
the pesky at sign gets in the way.
Signed-off-by: Andy Lutomirski <[email protected]>
---
scripts/Kbuild.include | 1 +
1 file changed, 1 insertion(+)
diff --git a/scripts/Kbuild.include b/scripts/Kbuild.include
index 122f95c..3e60923 100644
--- a/scripts/Kbuild.include
+++ b/scripts/Kbuild.include
@@ -194,6 +194,7 @@ echo-cmd = $(if $($(quiet)cmd_$(1)),\
# printing commands
cmd = @$(echo-cmd) $(cmd_$(1))
+recipe-cmd = $(echo-cmd) $(cmd_$(1))
# Add $(obj)/ for paths that are not absolute
objectify = $(foreach o,$(1),$(if $(filter /%,$(o)),$(o),$(obj)/$(o)))
--
1.9.3
Rather than monkeying with barely-comprehensible static pattern
rules, just use an explicit loop.
Signed-off-by: Andy Lutomirski <[email protected]>
---
arch/x86/vdso/Makefile | 20 +++++++-------------
1 file changed, 7 insertions(+), 13 deletions(-)
diff --git a/arch/x86/vdso/Makefile b/arch/x86/vdso/Makefile
index 9769df0..b1c70cc 100644
--- a/arch/x86/vdso/Makefile
+++ b/arch/x86/vdso/Makefile
@@ -9,11 +9,6 @@ VDSOX32-$(CONFIG_X86_X32_ABI) := y
VDSO32-$(CONFIG_X86_32) := y
VDSO32-$(CONFIG_COMPAT) := y
-vdso-install-$(VDSO64-y) += vdso.so
-vdso-install-$(VDSOX32-y) += vdsox32.so
-vdso-install-$(VDSO32-y) += $(vdso32-images)
-
-
# files to link into the vdso
vobjs-y := vdso-note.o vclock_gettime.o vgetcpu.o
@@ -176,15 +171,14 @@ VDSO_LDFLAGS = -fPIC -shared $(call cc-ldoption, -Wl$(comma)--hash-style=sysv) \
GCOV_PROFILE := n
#
-# Install the unstripped copy of vdso*.so listed in $(vdso-install-y).
+# Install the unstripped copies of vdso*.so listed in $(vdso-install-y).
#
-quiet_cmd_vdso_install = INSTALL $@
- cmd_vdso_install = cp $(obj)/[email protected] $(MODLIB)/vdso/$@
-$(vdso-install-y): %.so: $(obj)/%.so.dbg FORCE
- @mkdir -p $(MODLIB)/vdso
- $(call cmd,vdso_install)
+quiet_cmd_vdso_install = INSTALL $(sofile)
+ cmd_vdso_install = cp $(obj)/$(sofile).dbg $(MODLIB)/vdso/$(sofile)
-PHONY += vdso_install $(vdso-install-y)
-vdso_install: $(vdso-install-y)
+PHONY += vdso_install
+vdso_install: $(vdso_img_sodbg:%=$(obj)/%) FORCE
+ @mkdir -p $(MODLIB)/vdso
+ @$(foreach sofile,$(vdso_img_sodbg:%.dbg=%),$(call recipe-cmd,vdso_install);)
clean-files := vdso32-syscall* vdso32-sysenter* vdso32-int80*
--
1.9.3
On Wed, Jun 11, 2014 at 12:20 PM, Andy Lutomirski <[email protected]> wrote:
> This changes kbuild slightly because I didn't want to fight with using
> static pattern rules and extra obfuscated fake targets just to write a
> loop.
>
> Better ideas / cleanups welcome.
>
> Andy Lutomirski (2):
> kbuild: Add recipe-cmd, an @-less cmd variant
> x86,vdso: Fix vdso_install
You won the race :). I'll give these a spin shortly.
josh
On Wed, Jun 11, 2014 at 09:20:05AM -0700, Andy Lutomirski wrote:
> This changes kbuild slightly because I didn't want to fight with using
> static pattern rules and extra obfuscated fake targets just to write a
> loop.
What are you trying to fix with this?
On my box (32 bit Intel) "make MODLIB=~/mod vdso_install"
works as expected.
Two *.so files are installed as a copy of the so.dbg files.
Sam
On Wed, Jun 11, 2014 at 12:36 PM, Sam Ravnborg <[email protected]> wrote:
> On Wed, Jun 11, 2014 at 09:20:05AM -0700, Andy Lutomirski wrote:
>> This changes kbuild slightly because I didn't want to fight with using
>> static pattern rules and extra obfuscated fake targets just to write a
>> loop.
>
> What are you trying to fix with this?
>
> On my box (32 bit Intel) "make MODLIB=~/mod vdso_install"
> works as expected.
> Two *.so files are installed as a copy of the so.dbg files.
With what tree? With Linus' latest, I reported an error because
commit 6f121e548f83674ab4920a4e60afb58d4f61b829 breaks the
vdso_install target.
josh
On Wed, Jun 11, 2014 at 12:20 PM, Andy Lutomirski <[email protected]> wrote:
> Rather than monkeying with barely-comprehensible static pattern
> rules, just use an explicit loop.
>
> Signed-off-by: Andy Lutomirski <[email protected]>
> ---
> arch/x86/vdso/Makefile | 20 +++++++-------------
> 1 file changed, 7 insertions(+), 13 deletions(-)
>
> diff --git a/arch/x86/vdso/Makefile b/arch/x86/vdso/Makefile
> index 9769df0..b1c70cc 100644
> --- a/arch/x86/vdso/Makefile
> +++ b/arch/x86/vdso/Makefile
> @@ -9,11 +9,6 @@ VDSOX32-$(CONFIG_X86_X32_ABI) := y
> VDSO32-$(CONFIG_X86_32) := y
> VDSO32-$(CONFIG_COMPAT) := y
>
> -vdso-install-$(VDSO64-y) += vdso.so
> -vdso-install-$(VDSOX32-y) += vdsox32.so
> -vdso-install-$(VDSO32-y) += $(vdso32-images)
> -
> -
> # files to link into the vdso
> vobjs-y := vdso-note.o vclock_gettime.o vgetcpu.o
>
> @@ -176,15 +171,14 @@ VDSO_LDFLAGS = -fPIC -shared $(call cc-ldoption, -Wl$(comma)--hash-style=sysv) \
> GCOV_PROFILE := n
>
> #
> -# Install the unstripped copy of vdso*.so listed in $(vdso-install-y).
> +# Install the unstripped copies of vdso*.so listed in $(vdso-install-y).
> #
> -quiet_cmd_vdso_install = INSTALL $@
> - cmd_vdso_install = cp $(obj)/[email protected] $(MODLIB)/vdso/$@
> -$(vdso-install-y): %.so: $(obj)/%.so.dbg FORCE
> - @mkdir -p $(MODLIB)/vdso
> - $(call cmd,vdso_install)
> +quiet_cmd_vdso_install = INSTALL $(sofile)
> + cmd_vdso_install = cp $(obj)/$(sofile).dbg $(MODLIB)/vdso/$(sofile)
>
> -PHONY += vdso_install $(vdso-install-y)
> -vdso_install: $(vdso-install-y)
> +PHONY += vdso_install
> +vdso_install: $(vdso_img_sodbg:%=$(obj)/%) FORCE
> + @mkdir -p $(MODLIB)/vdso
> + @$(foreach sofile,$(vdso_img_sodbg:%.dbg=%),$(call recipe-cmd,vdso_install);)
So this does fix the invocation of 'make vdso_install' and the
resulting files look to be accurate to me, with the glaring exception
that now we get e.g. vdso64.so on x86_64 as the installed file instead
of vdso.so. How much that actually matters, I have no idea.
Plausibly fixed with a symlink if we really need to perhaps.
josh
On 06/11/2014 10:23 AM, Josh Boyer wrote:
>
> So this does fix the invocation of 'make vdso_install' and the
> resulting files look to be accurate to me, with the glaring exception
> that now we get e.g. vdso64.so on x86_64 as the installed file instead
> of vdso.so. How much that actually matters, I have no idea.
> Plausibly fixed with a symlink if we really need to perhaps.
>
You have that problem anyway, no? After all, there are three different
vdso images for 32 bits, and you can run 32-bit apps on 64-bit systems, too.
Is there realistically any way for the debugger to pick up the correct one?
-hpa
On Wed, Jun 11, 2014 at 1:27 PM, H. Peter Anvin <[email protected]> wrote:
> On 06/11/2014 10:23 AM, Josh Boyer wrote:
>>
>> So this does fix the invocation of 'make vdso_install' and the
>> resulting files look to be accurate to me, with the glaring exception
>> that now we get e.g. vdso64.so on x86_64 as the installed file instead
>> of vdso.so. How much that actually matters, I have no idea.
>> Plausibly fixed with a symlink if we really need to perhaps.
>>
>
> You have that problem anyway, no? After all, there are three different
> vdso images for 32 bits, and you can run 32-bit apps on 64-bit systems, too.
Yeah, true.
> Is there realistically any way for the debugger to pick up the correct one?
Probably not. I'm planning on pushing out our first 3.16 build with
these two patches with no symlink. I very much doubt anyone is going
to complain. It was just something I noticed.
josh
On Wed, Jun 11, 2014 at 10:33 AM, Josh Boyer <[email protected]> wrote:
> On Wed, Jun 11, 2014 at 1:27 PM, H. Peter Anvin <[email protected]> wrote:
>> On 06/11/2014 10:23 AM, Josh Boyer wrote:
>>>
>>> So this does fix the invocation of 'make vdso_install' and the
>>> resulting files look to be accurate to me, with the glaring exception
>>> that now we get e.g. vdso64.so on x86_64 as the installed file instead
>>> of vdso.so. How much that actually matters, I have no idea.
>>> Plausibly fixed with a symlink if we really need to perhaps.
>>>
>>
>> You have that problem anyway, no? After all, there are three different
>> vdso images for 32 bits, and you can run 32-bit apps on 64-bit systems, too.
>
> Yeah, true.
>
>> Is there realistically any way for the debugger to pick up the correct one?
>
> Probably not.
Sure there is: build ids. See /usr/lib/debug/.build-id.
It would be great if we could teach the various debugging tools
(libdw? gdb? I don't know what's responsible for the search path) to
search both /usr/lib/debug/.build-id and /lib/modules/`uname
-r`/build-id or something like that.
>
> I'm planning on pushing out our first 3.16 build with
> these two patches with no symlink. I very much doubt anyone is going
> to complain. It was just something I noticed.
Does the Fedora RPM magic debuginfo script notice these files and
symlink them into the .build-id directory?
Of course, we don't seem to be generating build ids right now. I
thought we were. I'll see if I can fix it.
--Andy
>
> josh
--
Andy Lutomirski
AMA Capital Management, LLC
On Wed, Jun 11, 2014 at 1:42 PM, Andy Lutomirski <[email protected]> wrote:
> On Wed, Jun 11, 2014 at 10:33 AM, Josh Boyer <[email protected]> wrote:
>> On Wed, Jun 11, 2014 at 1:27 PM, H. Peter Anvin <[email protected]> wrote:
>>> On 06/11/2014 10:23 AM, Josh Boyer wrote:
>>>>
>>>> So this does fix the invocation of 'make vdso_install' and the
>>>> resulting files look to be accurate to me, with the glaring exception
>>>> that now we get e.g. vdso64.so on x86_64 as the installed file instead
>>>> of vdso.so. How much that actually matters, I have no idea.
>>>> Plausibly fixed with a symlink if we really need to perhaps.
>>>>
>>>
>>> You have that problem anyway, no? After all, there are three different
>>> vdso images for 32 bits, and you can run 32-bit apps on 64-bit systems, too.
>>
>> Yeah, true.
>>
>>> Is there realistically any way for the debugger to pick up the correct one?
>>
>> Probably not.
>
> Sure there is: build ids. See /usr/lib/debug/.build-id.
Oh, duh.
> It would be great if we could teach the various debugging tools
> (libdw? gdb? I don't know what's responsible for the search path) to
> search both /usr/lib/debug/.build-id and /lib/modules/`uname
> -r`/build-id or something like that.
>
>>
>> I'm planning on pushing out our first 3.16 build with
>> these two patches with no symlink. I very much doubt anyone is going
>> to complain. It was just something I noticed.
>
> Does the Fedora RPM magic debuginfo script notice these files and
> symlink them into the .build-id directory?
>
> Of course, we don't seem to be generating build ids right now. I
> thought we were. I'll see if I can fix it.
My builds have it:
[jwboyer@sb ~]$ file /lib/modules/3.16.0-0.rc0.git1.1.fc21.x86_64/vdso/vdso64.so
/lib/modules/3.16.0-0.rc0.git1.1.fc21.x86_64/vdso/vdso64.so: ELF
64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically
linked, BuildID[sha1]=0x85ab0014891b5be97871e5e1183b761b9d2e8d9d,
stripped
[jwboyer@sb ~]$
I forget if we're doing something special to get that or not.
josh
On Wed, Jun 11, 2014 at 12:41:56PM -0400, Josh Boyer wrote:
> On Wed, Jun 11, 2014 at 12:36 PM, Sam Ravnborg <[email protected]> wrote:
> > On Wed, Jun 11, 2014 at 09:20:05AM -0700, Andy Lutomirski wrote:
> >> This changes kbuild slightly because I didn't want to fight with using
> >> static pattern rules and extra obfuscated fake targets just to write a
> >> loop.
> >
> > What are you trying to fix with this?
> >
> > On my box (32 bit Intel) "make MODLIB=~/mod vdso_install"
> > works as expected.
> > Two *.so files are installed as a copy of the so.dbg files.
>
> With what tree?
Linus latest - yes.
> With Linus' latest, I reported an error because
> commit 6f121e548f83674ab4920a4e60afb58d4f61b829 breaks the
> vdso_install target.
This is your bug-report: http://marc.info/?l=linux-kernel&m=140249607823283&w=2
+ make -s ARCH=x86_64
INSTALL_MOD_PATH=/home/jwboyer/rpmbuild/BUILDROOT/kernel-3.16.0-0.rc0.git1.1.fc21.x86_64
vdso_install KERNELRELEASE=3.16.0-0.rc0.git1.1.fc21.x86_64
make[1]: *** No rule to make target `arch/x86/vdso/vdso.so.dbg',
needed by `vdso.so'. Stop.
make: *** [vdso_install] Error 2
I am building for i386 which is why I do not see the bug.
Sam
On Wed, Jun 11, 2014 at 10:45 AM, Josh Boyer <[email protected]> wrote:
> On Wed, Jun 11, 2014 at 1:42 PM, Andy Lutomirski <[email protected]> wrote:
>> On Wed, Jun 11, 2014 at 10:33 AM, Josh Boyer <[email protected]> wrote:
>>> On Wed, Jun 11, 2014 at 1:27 PM, H. Peter Anvin <[email protected]> wrote:
>>>> On 06/11/2014 10:23 AM, Josh Boyer wrote:
>>>>>
>>>>> So this does fix the invocation of 'make vdso_install' and the
>>>>> resulting files look to be accurate to me, with the glaring exception
>>>>> that now we get e.g. vdso64.so on x86_64 as the installed file instead
>>>>> of vdso.so. How much that actually matters, I have no idea.
>>>>> Plausibly fixed with a symlink if we really need to perhaps.
>>>>>
>>>>
>>>> You have that problem anyway, no? After all, there are three different
>>>> vdso images for 32 bits, and you can run 32-bit apps on 64-bit systems, too.
>>>
>>> Yeah, true.
>>>
>>>> Is there realistically any way for the debugger to pick up the correct one?
>>>
>>> Probably not.
>>
>> Sure there is: build ids. See /usr/lib/debug/.build-id.
>
> Oh, duh.
>
>> It would be great if we could teach the various debugging tools
>> (libdw? gdb? I don't know what's responsible for the search path) to
>> search both /usr/lib/debug/.build-id and /lib/modules/`uname
>> -r`/build-id or something like that.
>>
>>>
>>> I'm planning on pushing out our first 3.16 build with
>>> these two patches with no symlink. I very much doubt anyone is going
>>> to complain. It was just something I noticed.
>>
>> Does the Fedora RPM magic debuginfo script notice these files and
>> symlink them into the .build-id directory?
>>
>> Of course, we don't seem to be generating build ids right now. I
>> thought we were. I'll see if I can fix it.
>
> My builds have it:
>
> [jwboyer@sb ~]$ file /lib/modules/3.16.0-0.rc0.git1.1.fc21.x86_64/vdso/vdso64.so
> /lib/modules/3.16.0-0.rc0.git1.1.fc21.x86_64/vdso/vdso64.so: ELF
> 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically
> linked, BuildID[sha1]=0x85ab0014891b5be97871e5e1183b761b9d2e8d9d,
> stripped
> [jwboyer@sb ~]$
>
> I forget if we're doing something special to get that or not.
Apparently not. file can see it, but apparently objdump can't. go figure.
>
> josh
--
Andy Lutomirski
AMA Capital Management, LLC
On Wed, Jun 11, 2014 at 01:23:59PM -0400, Josh Boyer wrote:
> On Wed, Jun 11, 2014 at 12:20 PM, Andy Lutomirski <[email protected]> wrote:
> > Rather than monkeying with barely-comprehensible static pattern
> > rules, just use an explicit loop.
> >
> > Signed-off-by: Andy Lutomirski <[email protected]>
> > ---
> > arch/x86/vdso/Makefile | 20 +++++++-------------
> > 1 file changed, 7 insertions(+), 13 deletions(-)
> >
> > diff --git a/arch/x86/vdso/Makefile b/arch/x86/vdso/Makefile
> > index 9769df0..b1c70cc 100644
> > --- a/arch/x86/vdso/Makefile
> > +++ b/arch/x86/vdso/Makefile
> > @@ -9,11 +9,6 @@ VDSOX32-$(CONFIG_X86_X32_ABI) := y
> > VDSO32-$(CONFIG_X86_32) := y
> > VDSO32-$(CONFIG_COMPAT) := y
> >
> > -vdso-install-$(VDSO64-y) += vdso.so
> > -vdso-install-$(VDSOX32-y) += vdsox32.so
> > -vdso-install-$(VDSO32-y) += $(vdso32-images)
> > -
> > -
> > # files to link into the vdso
> > vobjs-y := vdso-note.o vclock_gettime.o vgetcpu.o
> >
> > @@ -176,15 +171,14 @@ VDSO_LDFLAGS = -fPIC -shared $(call cc-ldoption, -Wl$(comma)--hash-style=sysv) \
> > GCOV_PROFILE := n
> >
> > #
> > -# Install the unstripped copy of vdso*.so listed in $(vdso-install-y).
> > +# Install the unstripped copies of vdso*.so listed in $(vdso-install-y).
> > #
> > -quiet_cmd_vdso_install = INSTALL $@
> > - cmd_vdso_install = cp $(obj)/[email protected] $(MODLIB)/vdso/$@
> > -$(vdso-install-y): %.so: $(obj)/%.so.dbg FORCE
> > - @mkdir -p $(MODLIB)/vdso
> > - $(call cmd,vdso_install)
> > +quiet_cmd_vdso_install = INSTALL $(sofile)
> > + cmd_vdso_install = cp $(obj)/$(sofile).dbg $(MODLIB)/vdso/$(sofile)
> >
> > -PHONY += vdso_install $(vdso-install-y)
> > -vdso_install: $(vdso-install-y)
> > +PHONY += vdso_install
> > +vdso_install: $(vdso_img_sodbg:%=$(obj)/%) FORCE
> > + @mkdir -p $(MODLIB)/vdso
> > + @$(foreach sofile,$(vdso_img_sodbg:%.dbg=%),$(call recipe-cmd,vdso_install);)
Can we please fix this in a way where we do not need to add stuff to core kbuild.
If the original approach was used then make took care of the looping
and the foreach part was not needed.
Sam
On Wed, Jun 11, 2014 at 11:44 AM, Sam Ravnborg <[email protected]> wrote:
> On Wed, Jun 11, 2014 at 12:41:56PM -0400, Josh Boyer wrote:
>> On Wed, Jun 11, 2014 at 12:36 PM, Sam Ravnborg <[email protected]> wrote:
>> > On Wed, Jun 11, 2014 at 09:20:05AM -0700, Andy Lutomirski wrote:
>> >> This changes kbuild slightly because I didn't want to fight with using
>> >> static pattern rules and extra obfuscated fake targets just to write a
>> >> loop.
>> >
>> > What are you trying to fix with this?
>> >
>> > On my box (32 bit Intel) "make MODLIB=~/mod vdso_install"
>> > works as expected.
>> > Two *.so files are installed as a copy of the so.dbg files.
>>
>> With what tree?
> Linus latest - yes.
>
>> With Linus' latest, I reported an error because
>> commit 6f121e548f83674ab4920a4e60afb58d4f61b829 breaks the
>> vdso_install target.
> This is your bug-report: http://marc.info/?l=linux-kernel&m=140249607823283&w=2
>
> + make -s ARCH=x86_64
> INSTALL_MOD_PATH=/home/jwboyer/rpmbuild/BUILDROOT/kernel-3.16.0-0.rc0.git1.1.fc21.x86_64
> vdso_install KERNELRELEASE=3.16.0-0.rc0.git1.1.fc21.x86_64
> make[1]: *** No rule to make target `arch/x86/vdso/vdso.so.dbg',
> needed by `vdso.so'. Stop.
> make: *** [vdso_install] Error 2
>
> I am building for i386 which is why I do not see the bug.
I didn't actually check whether all of the code I removed in the patch
was wrong or just some.
If you have a better suggestion for how to structure the makefile
rule, I'd be interested. I don't speak makefilese very well.
--Andy
On Wed, Jun 11, 2014 at 11:51 AM, Sam Ravnborg <[email protected]> wrote:
> On Wed, Jun 11, 2014 at 01:23:59PM -0400, Josh Boyer wrote:
>> On Wed, Jun 11, 2014 at 12:20 PM, Andy Lutomirski <[email protected]> wrote:
>> > Rather than monkeying with barely-comprehensible static pattern
>> > rules, just use an explicit loop.
>> >
>> > Signed-off-by: Andy Lutomirski <[email protected]>
>> > ---
>> > arch/x86/vdso/Makefile | 20 +++++++-------------
>> > 1 file changed, 7 insertions(+), 13 deletions(-)
>> >
>> > diff --git a/arch/x86/vdso/Makefile b/arch/x86/vdso/Makefile
>> > index 9769df0..b1c70cc 100644
>> > --- a/arch/x86/vdso/Makefile
>> > +++ b/arch/x86/vdso/Makefile
>> > @@ -9,11 +9,6 @@ VDSOX32-$(CONFIG_X86_X32_ABI) := y
>> > VDSO32-$(CONFIG_X86_32) := y
>> > VDSO32-$(CONFIG_COMPAT) := y
>> >
>> > -vdso-install-$(VDSO64-y) += vdso.so
>> > -vdso-install-$(VDSOX32-y) += vdsox32.so
>> > -vdso-install-$(VDSO32-y) += $(vdso32-images)
>> > -
>> > -
>> > # files to link into the vdso
>> > vobjs-y := vdso-note.o vclock_gettime.o vgetcpu.o
>> >
>> > @@ -176,15 +171,14 @@ VDSO_LDFLAGS = -fPIC -shared $(call cc-ldoption, -Wl$(comma)--hash-style=sysv) \
>> > GCOV_PROFILE := n
>> >
>> > #
>> > -# Install the unstripped copy of vdso*.so listed in $(vdso-install-y).
>> > +# Install the unstripped copies of vdso*.so listed in $(vdso-install-y).
>> > #
>> > -quiet_cmd_vdso_install = INSTALL $@
>> > - cmd_vdso_install = cp $(obj)/[email protected] $(MODLIB)/vdso/$@
>> > -$(vdso-install-y): %.so: $(obj)/%.so.dbg FORCE
>> > - @mkdir -p $(MODLIB)/vdso
>> > - $(call cmd,vdso_install)
>> > +quiet_cmd_vdso_install = INSTALL $(sofile)
>> > + cmd_vdso_install = cp $(obj)/$(sofile).dbg $(MODLIB)/vdso/$(sofile)
>> >
>> > -PHONY += vdso_install $(vdso-install-y)
>> > -vdso_install: $(vdso-install-y)
>> > +PHONY += vdso_install
>> > +vdso_install: $(vdso_img_sodbg:%=$(obj)/%) FORCE
>> > + @mkdir -p $(MODLIB)/vdso
>> > + @$(foreach sofile,$(vdso_img_sodbg:%.dbg=%),$(call recipe-cmd,vdso_install);)
>
> Can we please fix this in a way where we do not need to add stuff to core kbuild.
> If the original approach was used then make took care of the looping
> and the foreach part was not needed.
Would expanding out the cmd macro here be okay? Or is that too
dependent on kbuild internals?
I can fiddle with static patterns again (ugh).
--Andy
> >
> > Can we please fix this in a way where we do not need to add stuff to core kbuild.
> > If the original approach was used then make took care of the looping
> > and the foreach part was not needed.
Following is my first quick approach.
It reuses the old - a little complex logic to do the looping and copying.
Thsi is only tested on my i386 box / build.
Sam
diff --git a/arch/x86/vdso/Makefile b/arch/x86/vdso/Makefile
index 9769df0..39fb152 100644
--- a/arch/x86/vdso/Makefile
+++ b/arch/x86/vdso/Makefile
@@ -9,11 +9,6 @@ VDSOX32-$(CONFIG_X86_X32_ABI) := y
VDSO32-$(CONFIG_X86_32) := y
VDSO32-$(CONFIG_COMPAT) := y
-vdso-install-$(VDSO64-y) += vdso.so
-vdso-install-$(VDSOX32-y) += vdsox32.so
-vdso-install-$(VDSO32-y) += $(vdso32-images)
-
-
# files to link into the vdso
vobjs-y := vdso-note.o vclock_gettime.o vgetcpu.o
@@ -179,12 +174,12 @@ GCOV_PROFILE := n
# Install the unstripped copy of vdso*.so listed in $(vdso-install-y).
#
quiet_cmd_vdso_install = INSTALL $@
- cmd_vdso_install = cp $(obj)/[email protected] $(MODLIB)/vdso/$@
-$(vdso-install-y): %.so: $(obj)/%.so.dbg FORCE
+ cmd_vdso_install = cp $(obj)/$@ $(MODLIB)/vdso/$(@:.dbg=)
+$(vdso_img_sodbg): %.so.dbg: $(obj)/%.so.dbg FORCE
@mkdir -p $(MODLIB)/vdso
$(call cmd,vdso_install)
-PHONY += vdso_install $(vdso-install-y)
-vdso_install: $(vdso-install-y)
+PHONY += vdso_install $(vdso_img_sodbg)
+vdso_install: $(vdso_img_sodbg)
clean-files := vdso32-syscall* vdso32-sysenter* vdso32-int80*
On Wed, Jun 11, 2014 at 12:16 PM, Sam Ravnborg <[email protected]> wrote:
>> >
>> > Can we please fix this in a way where we do not need to add stuff to core kbuild.
>> > If the original approach was used then make took care of the looping
>> > and the foreach part was not needed.
> Following is my first quick approach.
> It reuses the old - a little complex logic to do the looping and copying.
> Thsi is only tested on my i386 box / build.
>
> Sam
>
>
> diff --git a/arch/x86/vdso/Makefile b/arch/x86/vdso/Makefile
> index 9769df0..39fb152 100644
> --- a/arch/x86/vdso/Makefile
> +++ b/arch/x86/vdso/Makefile
> @@ -9,11 +9,6 @@ VDSOX32-$(CONFIG_X86_X32_ABI) := y
> VDSO32-$(CONFIG_X86_32) := y
> VDSO32-$(CONFIG_COMPAT) := y
>
> -vdso-install-$(VDSO64-y) += vdso.so
> -vdso-install-$(VDSOX32-y) += vdsox32.so
> -vdso-install-$(VDSO32-y) += $(vdso32-images)
> -
> -
> # files to link into the vdso
> vobjs-y := vdso-note.o vclock_gettime.o vgetcpu.o
>
> @@ -179,12 +174,12 @@ GCOV_PROFILE := n
> # Install the unstripped copy of vdso*.so listed in $(vdso-install-y).
> #
> quiet_cmd_vdso_install = INSTALL $@
> - cmd_vdso_install = cp $(obj)/[email protected] $(MODLIB)/vdso/$@
> -$(vdso-install-y): %.so: $(obj)/%.so.dbg FORCE
> + cmd_vdso_install = cp $(obj)/$@ $(MODLIB)/vdso/$(@:.dbg=)
> +$(vdso_img_sodbg): %.so.dbg: $(obj)/%.so.dbg FORCE
> @mkdir -p $(MODLIB)/vdso
> $(call cmd,vdso_install)
The part that scares me is that this rule defines targets with names
like vdso64.so.dbg, which are the names of actual files (admittedly,
they're missing the path, but still). This seems fragile.
>
> -PHONY += vdso_install $(vdso-install-y)
> -vdso_install: $(vdso-install-y)
> +PHONY += vdso_install $(vdso_img_sodbg)
> +vdso_install: $(vdso_img_sodbg)
>
> clean-files := vdso32-syscall* vdso32-sysenter* vdso32-int80*
>
--
Andy Lutomirski
AMA Capital Management, LLC
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.
hpa, can I depend on an x32 toolchain for the x32 build?
--Andy
On Tue, Jun 17, 2014 at 3:54 PM, Andy Lutomirski <[email protected]> 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?
--Andy
On 06/17/2014 08:45 PM, Andy Lutomirski wrote:
> On Tue, Jun 17, 2014 at 3:54 PM, Andy Lutomirski <[email protected]> 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.
-hpa
On Tue, Jun 17, 2014 at 8:48 PM, H. Peter Anvin <[email protected]> wrote:
> On 06/17/2014 08:45 PM, Andy Lutomirski wrote:
>> On Tue, Jun 17, 2014 at 3:54 PM, Andy Lutomirski <[email protected]> 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
On Wed, Jun 18, 2014 at 12:22 AM, Andy Lutomirski <[email protected]> wrote:
> On Tue, Jun 17, 2014 at 8:48 PM, H. Peter Anvin <[email protected]> wrote:
>> On 06/17/2014 08:45 PM, Andy Lutomirski wrote:
>>> On Tue, Jun 17, 2014 at 3:54 PM, Andy Lutomirski <[email protected]> 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.
> 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.
> 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.
josh
On Wed, Jun 18, 2014 at 6:09 AM, Josh Boyer <[email protected]> wrote:
> On Wed, Jun 18, 2014 at 12:22 AM, Andy Lutomirski <[email protected]> wrote:
>> On Tue, Jun 17, 2014 at 8:48 PM, H. Peter Anvin <[email protected]> wrote:
>>> On 06/17/2014 08:45 PM, Andy Lutomirski wrote:
>>>> On Tue, Jun 17, 2014 at 3:54 PM, Andy Lutomirski <[email protected]> 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