interesting option of stap

interesting option of stap

[Turgis, Frederic]

Hi,

I encountered build issues on ARM because compiler was emitting warnings, caught as errors through -Werror option. I related that to some omit_werror config option and finally to "stfu-kbuild-i-know-better" option (kind of hidden in the code through 6 "OWEx" macros). It is still present on latest code, is it supposed to be viable or some option I shall immediately forget ?


Regards
Fred

Frederic Turgis
OMAP Platform Business Unit - OMAP System Engineering - Platform Enablement


Texas Instruments France SA, 821 Avenue Jack Kilby, 06270 Villeneuve Loubet. 036 420 040 R.C.S Antibes. Capital de EUR 753.920

Re: interesting option of stap

[William Cohen]

On 02/16/2011 01:38 PM, Turgis, Frederic wrote:
> Hi,
> 
> I encountered build issues on ARM because compiler was emitting warnings, caught as errors through -Werror option. I related that to some omit_werror config option and finally to "stfu-kbuild-i-know-better" option (kind of hidden in the code through 6 "OWEx" macros). It is still present on latest code, is it supposed to be viable or some option I shall immediately forget ?
> 
> 
> Regards
> Fred
> 
> Frederic Turgis
> OMAP Platform Business Unit - OMAP System Engineering - Platform Enablement
> 
> 
> Texas Instruments France SA, 821 Avenue Jack Kilby, 06270 Villeneuve Loubet. 036 420 040 R.C.S Antibes. Capital de EUR 753.920
> 
> 
> 


Hi Fred,

In theory systemtap should be generating code that compiles without warnings during the module creation, but in practice we don't check things on ARM as much as we would like.

Could you include the error message output? Was the error messages due to headers outside of systemtap or were they the results of code generated by systemtap?

-Will

Re: interesting option of stap

[Frank Ch. Eigler]

"Turgis, Frederic" <f-turgis@ti.com> writes:

> [The -Werror-suppress option] is still present on latest co= de, is
> it supposed to be viable or some option I shall immediately forget ?

You are hereby granted dispensation to use it, as long as you never
mention it again. :)

- FChE

RE: interesting option of stap

[Turgis, Frederic]

Hello,

It seems nobody wants to comment the nice "--stfu-kbuild-i-know-better" option ;-)


I was going to address the issue through another thread (or eventually bug report) but let's do it now.

.build_id_offset=0xffffffffxxxxxxxx in stap-symbols.h. Therefore we get a warning that it gets truncated for ARM architecture.


However, I just tested with latest code whereas I started with v1.4. Problem is no longer present. ".build_id_offset" is not present in stap-symbols.h. Eventually there can be a difference in my setup because I am doing it remotely.
I will follow-up if I still see that tomorrow in front of my desktop.

Regards
Fred


Frederic Turgis
OMAP Platform Business Unit - OMAP System Engineering - Platform Enablement



Texas Instruments France SA, 821 Avenue Jack Kilby, 06270 Villeneuve Loubet. 036 420 040 R.C.S Antibes. Capital de EUR 753.920

-----Original Message-----

From: systemtap-owner@sourceware.org [mailto:systemtap-owner@sourceware.org] On Behalf Of William Cohen
Sent: Wednesday, February 16, 2011 7:55 PM
To: systemtap@sourceware.org
Subject: Re: interesting option of stap

On 02/16/2011 01:38 PM, Turgis, Frederic wrote:
> Hi,
>
> I encountered build issues on ARM because compiler was emitting warnings, caught as errors through -Werror option. I related that to some omit_werror config option and finally to "stfu-kbuild-i-know-better" option (kind of hidden in the code through 6 "OWEx" macros). It is still present on latest code, is it supposed to be viable or some option I shall immediately forget ?
>
>
> Regards
> Fred
>
> Frederic Turgis
> OMAP Platform Business Unit - OMAP System Engineering - Platform
> Enablement
>
>
> Texas Instruments France SA, 821 Avenue Jack Kilby, 06270 Villeneuve
> Loubet. 036 420 040 R.C.S Antibes. Capital de EUR 753.920
>
>
>


Hi Fred,

In theory systemtap should be generating code that compiles without warnings during the module creation, but in practice we don't check things on ARM as much as we would like.

Could you include the error message output? Was the error messages due to headers outside of systemtap or were they the results of code generated by systemtap?

-Will

RE: interesting option of stap

[Turgis, Frederic]

Hello,

Bug is actually present, it was OK only due to a typo (stap instead of ./stap).

/tmp/staprfxbPV/stap-symbols.h:127376: error: integer constant is too large for 'long' type
/tmp/staprfxbPV/stap-symbols.h:127376: error: large integer implicitly truncated to unsigned type

static struct _stp_module _stp_module_0 = {
...
.build_id_len = 20,
.build_id_offset = 0xffffffff3fff8010, -> here is the issue for ARM
.notes_sect = 0,
};

Regards
Fred


Frederic Turgis

OMAP Platform Business Unit - OMAP System Engineering - Platform Enablement



Texas Instruments France SA, 821 Avenue Jack Kilby, 06270 Villeneuve Loubet. 036 420 040 R.C.S Antibes. Capital de EUR 753.920

-----Original Message-----

From: systemtap-owner@sourceware.org [mailto:systemtap-owner@sourceware.org] On Behalf Of Turgis, Frederic
Sent: Wednesday, February 16, 2011 9:45 PM
To: William Cohen; systemtap@sourceware.org
Subject: RE: interesting option of stap

Hello,

It seems nobody wants to comment the nice "--stfu-kbuild-i-know-better" option ;-)


I was going to address the issue through another thread (or eventually bug report) but let's do it now.

.build_id_offset=0xffffffffxxxxxxxx in stap-symbols.h. Therefore we get a warning that it gets truncated for ARM architecture.


However, I just tested with latest code whereas I started with v1.4. Problem is no longer present. ".build_id_offset" is not present in stap-symbols.h. Eventually there can be a difference in my setup because I am doing it remotely.
I will follow-up if I still see that tomorrow in front of my desktop.

Regards
Fred


Frederic Turgis
OMAP Platform Business Unit - OMAP System Engineering - Platform Enablement



Texas Instruments France SA, 821 Avenue Jack Kilby, 06270 Villeneuve Loubet. 036 420 040 R.C.S Antibes. Capital de EUR 753.920

-----Original Message-----

From: systemtap-owner@sourceware.org [mailto:systemtap-owner@sourceware.org] On Behalf Of William Cohen
Sent: Wednesday, February 16, 2011 7:55 PM
To: systemtap@sourceware.org
Subject: Re: interesting option of stap

On 02/16/2011 01:38 PM, Turgis, Frederic wrote:
> Hi,
>
> I encountered build issues on ARM because compiler was emitting warnings, caught as errors through -Werror option. I related that to some omit_werror config option and finally to "stfu-kbuild-i-know-better" option (kind of hidden in the code through 6 "OWEx" macros). It is still present on latest code, is it supposed to be viable or some option I shall immediately forget ?
>
>
> Regards
> Fred
>
> Frederic Turgis
> OMAP Platform Business Unit - OMAP System Engineering - Platform
> Enablement
>
>
> Texas Instruments France SA, 821 Avenue Jack Kilby, 06270 Villeneuve
> Loubet. 036 420 040 R.C.S Antibes. Capital de EUR 753.920
>
>
>


Hi Fred,

In theory systemtap should be generating code that compiles without warnings during the module creation, but in practice we don't check things on ARM as much as we would like.

Could you include the error message output? Was the error messages due to headers outside of systemtap or were they the results of code generated by systemtap?

-Will

Re: interesting option of stap

[William Cohen]

[-- Attachment #1: Type: text/plain, Size: 1329 bytes --]

On 02/19/2011 06:01 PM, Turgis, Frederic wrote:
> Hello,
> 
> Bug is actually present, it was OK only due to a typo (stap instead of ./stap).
> 
> /tmp/staprfxbPV/stap-symbols.h:127376: error: integer constant is too large for 'long' type
> /tmp/staprfxbPV/stap-symbols.h:127376: error: large integer implicitly truncated to unsigned type
> 
> static struct _stp_module _stp_module_0 = {
> ...
> .build_id_len = 20,
> .build_id_offset = 0xffffffff3fff8010, -> here is the issue for ARM
> .notes_sect = 0,
> };
> 
> Regards
> Fred

I looked where the constant is generated, translate.cxx. The constant being printed out is type GElf_Addr. In /usr/include/gelf.h that is a 64 bit type:

typedef Elf64_Addr GElf_Addr;

However, /usr/share/systemtap/runtime/sym.h struct _stp_module has the following:

	unsigned long  build_id_offset;

The attached patch would generate constants that match the type for build_id_offset field. However, I am not sure if that is entirely correct fix. 0xffffffff3fff8010 is a negative number with a really large magnitude. The stap "-vv" option should include output like the following:

Found build-id in kernel, length 20, start at 0xffffffff814d2b50

That would be able to determine whether build_id_vaddr is wrong or whether (base+extra_offset) in translate.cxx:dump_unwindsyms() is wrong.

-Will

[-- Attachment #2: build_cast.diff --]
[-- Type: text/x-patch, Size: 1280 bytes --]

diff --git a/translate.cxx b/translate.cxx
index 82f3ee4..55acdb0 100644
--- a/translate.cxx
+++ b/translate.cxx
@@ -4951,7 +4951,7 @@ dump_unwindsyms (Dwfl_Module *m,
       {
         clog << "Found build-id in " << name
              << ", length " << build_id_len;
-        clog << ", start at 0x" << hex << build_id_vaddr
+        clog << ", start at 0x" << hex << (unsigned long) build_id_vaddr
              << dec << endl;
       }
   }
@@ -5406,12 +5406,12 @@ dump_unwindsyms (Dwfl_Module *m,
        correct either.  We may instead need a relocation basis different
        from _stext, such as __start_notes.  */
     if (modname == "kernel")
-      c->output << ".build_id_offset = 0x" << hex << build_id_vaddr - (base + extra_offset)
+	    c->output << ".build_id_offset = 0x" << hex << (unsigned long) build_id_vaddr - (base + extra_offset)
                 << dec << ",\n";
     // ET_DYN: task finder gives the load address. ET_EXEC: this is absolute address
     else
-      c->output << ".build_id_offset = 0x" << hex
-                << build_id_vaddr /* - base */
+	c->output << ".build_id_offset = 0x" << hex
+                << (unsigned long) build_id_vaddr /* - base */
                 << dec << ",\n";
   } else
     c->output << ".build_id_len = 0,\n";

Re: interesting option of stap

[Roland McGrath]

It looks like a bug in the relocatability code to me.  That looks like a
negative offset coming out, and it should never be negative.  Perhaps
Frederic can make available the ARM binary that "module 0" refers to,
so we can investigate the analysis stap is doing it.

Thanks,
Roland

RE: interesting option of stap

[Turgis, Frederic]

Thanks for you help,

With -vvv, I get:

dump_unwindsyms kernel index=0 base=0x0
Found build-id in kernel, length 20, start at 0x10 -> so build_id_vaddr = 0x10
Found kernel _stext extra offset 0xc0008000 -> extra_offset=0xC0008000. Effectively, 0xc0008000 is the _stext section address I can see in my System.map

As modname is kernel, we execute:
c->output << ".build_id_offset = 0x" << hex << build_id_vaddr - (base + extra_offset)

i.e. 0x10 - (0x0 + 0xC0008000) = 0xFFFFFFFF 3FFF8010, which is what I get in stap-symbols.h


With --stfu-kbuild-i-know-better, the generated .ko with the warning seemed to work OK. So the patch from William would probably work. But I am not following everything about this 64bits elf address and this build_id_offset that is a long.
By the way, my elf-utils lib is .143, which seems recent enough.

And I don't see which binary "module 0" refers to. Where shall I find it ?

Regards
Fred

Frederic Turgis
OMAP Platform Business Unit - OMAP System Engineering - Platform Enablement



Texas Instruments France SA, 821 Avenue Jack Kilby, 06270 Villeneuve Loubet. 036 420 040 R.C.S Antibes. Capital de EUR 753.920

-----Original Message-----

From: Roland McGrath [mailto:roland@redhat.com]
Sent: Monday, February 21, 2011 8:23 PM
To: William Cohen
Cc: Turgis, Frederic; systemtap@sourceware.org
Subject: Re: interesting option of stap

It looks like a bug in the relocatability code to me.  That looks like a negative offset coming out, and it should never be negative.  Perhaps Frederic can make available the ARM binary that "module 0" refers to, so we can investigate the analysis stap is doing it.

Thanks,
Roland

RE: interesting option of stap

[Roland McGrath]

It appears your kernel binary is the one we need to see (vmlinux).  If
it has a separate .debug file, we may need that too.  (Compress the
files before you give them to us.)  Don't post large attachments to
the mailing list.  If you can make the files available for download,
that is best.  If that is not convenient, you can mail them to me
privately.


Thanks,
Roland

RE: interesting option of stap

[Turgis, Frederic]

Hello,

Bzip2 compressed vmlinux is at http://dl.free.fr/aw6H5Y8G6 (username is whatever you want like "xxx", password is "systemtap"). Tell me if you need more, debug info shall be inside. I only have a System.map aside that.


Regards
Fred


Frederic Turgis

OMAP Platform Business Unit - OMAP System Engineering - Platform Enablement



Texas Instruments France SA, 821 Avenue Jack Kilby, 06270 Villeneuve Loubet. 036 420 040 R.C.S Antibes. Capital de EUR 753.920

-----Original Message-----

From: Roland McGrath [mailto:roland@redhat.com]
Sent: Tuesday, February 22, 2011 1:23 AM
To: Turgis, Frederic
Cc: William Cohen; systemtap@sourceware.org
Subject: RE: interesting option of stap

It appears your kernel binary is the one we need to see (vmlinux).  If it has a separate .debug file, we may need that too.  (Compress the files before you give them to us.)  Don't post large attachments to the mailing list.  If you can make the files available for download, that is best.  If that is not convenient, you can mail them to me privately.


Thanks,
Roland

RE: interesting option of stap

[Roland McGrath]

Ok, this kernel image looks like it's just been linked wrong.  
The build ID is placed at address 0, somewhere that is probably
not actually loaded into memory by the boot loader at all.

Perhaps this is a build of a kernel that doesn't have the various
changes that were added upstream when --build-id was introduced?  

In recent upstream kernel sources, arch/arm/kernel/vmlinux.lds.S uses
the NOTES macro, which should place the .note.gnu.build-id section
near the end of the image.  This is not really right either, but it
doesn't look like it should result in what your kernel image has.
In other machines' kernel linker scripts, the NOTES macro is placed
such that it appears next to the rodata (RO_DATA macro), which is a
sensible place for it.


Thanks,
Roland

RE: interesting option of stap

[Turgis, Frederic]

I provided you with our Android kernel (arm architecture of course). I checked some other Android kernel, 1 ubuntu kernel and 1 Linaro OMAP kernel, they all have .note.gnu.build-id section at 0 !!

I will have a look at upstream vmlinux.lds.S (and NOTES macro) vs ours.

Regards
Fred

Frederic Turgis
OMAP Platform Business Unit - OMAP System Engineering - Platform Enablement



Texas Instruments France SA, 821 Avenue Jack Kilby, 06270 Villeneuve Loubet. 036 420 040 R.C.S Antibes. Capital de EUR 753.920

-----Original Message-----

From: Roland McGrath [mailto:roland@redhat.com]
Sent: Tuesday, February 22, 2011 11:37 PM
To: Turgis, Frederic
Cc: William Cohen; systemtap@sourceware.org
Subject: RE: interesting option of stap

Ok, this kernel image looks like it's just been linked wrong.
The build ID is placed at address 0, somewhere that is probably not actually loaded into memory by the boot loader at all.

Perhaps this is a build of a kernel that doesn't have the various changes that were added upstream when --build-id was introduced?

In recent upstream kernel sources, arch/arm/kernel/vmlinux.lds.S uses the NOTES macro, which should place the .note.gnu.build-id section near the end of the image.  This is not really right either, but it doesn't look like it should result in what your kernel image has.
In other machines' kernel linker scripts, the NOTES macro is placed such that it appears next to the rodata (RO_DATA macro), which is a sensible place for it.


Thanks,
Roland

RE: interesting option of stap

[Roland McGrath]

> I provided you with our Android kernel (arm architecture of course). I checked some other Android kernel, 1 ubuntu kernel and 1 Linaro OMAP kernel, they all have .note.gnu.build-id section at 0 !!
> 
> I will have a look at upstream vmlinux.lds.S (and NOTES macro) vs ours.

I looked at git://android.git.kernel.org/kernel/common.git on a guess
that it might be an approximate basis for the code you're talking about.

arch/arm/kernel/vmlinux.lds.S there indeed lacks any use of the NOTES
macro.  I think the place it probably belongs is before the use of the
RO_DATA macro.  I suspect that would make the build ID note come out
correctly.  You can look at the output of (eu-)readelf -S on the resultant
vmlinux file and that will indicate sufficiently for us to tell how it
went.  If you get such a kernel running, you can also look at 'hexdump -C
/sys/kernel/notes' to see if the notes got into the kernel properly so
they can be interrogated at runtime (this is used by some other tools to
locate the debuginfo that goes with the running kernel, though systemtap
does not rely on this).


Thanks,
Roland

RE: interesting option of stap

[Turgis, Frederic]

Hello,

Hopefully I already digged some time ago in linker cmd file syntax and initcall stuff so I am not 100% lost ;-). Here are my findings:

- kernels mentioned are for example at git.linaro.org (ubuntu based) or gitorious.org/pandroid... But android.git.kernel.org is a good source too. I was using objdump -h on vmlinux when I stated that .note.gnu.build-id is at location 0. Same results than readelf I guess.
I don't find any use of NOTES in vmlinux.lds.S although vmlinux.lds.h mentions that minimal linker cmd file shall contain it.

- /sys/kernel/notes does not exist on these kernels. I found in all my kernels in .zImage.cmd "arm-linux-gnueabi-objcopy ... -R .note -R .note.gnu.build-id ... arch/arm/boot/compressed/vmlinux arch/arm/boot/zImage", -R being "Remove section xxx from the output". That could be why I don't see "notes" in the kernel.


Well, digging further, I simply read again the code and I found:
  /* Don't save build-id if it is located before _stext.
   * This probably means that build-id will not be loaded at all and
   * happens for example with ARM kernel.
   *
   * See also:
   *    http://sources.redhat.com/ml/systemtap/2009-q4/msg00574.html
   */
  if (build_id_len > 0 && (build_id_vaddr > base + extra_offset)) {


-> html page is about the same problem on an ARM kernel. And the "build_id_vaddr >" test comes from commit 66f65c4fb0ddcdf8a85a29662a23a546cfd5dffe in 2009-12-15.

Test was removed in commit 155bb07a5bfdd16b112870f7064f012970b7fbd9 in 2010-11-06 related to user modules. That's why I see the problem in v1.4 and why I don't have build_id_offset in stap-symbols.h in v1.3. I guess test shall be reintroduced for kernel modules.


Although that fixes the issue, I will still ask Linaro guys about this build-id section that is removed in arch/arm/Makefile flags.


Thanks for the help

Regards
Fred


Frederic Turgis
OMAP Platform Business Unit - OMAP System Engineering - Platform Enablement



Texas Instruments France SA, 821 Avenue Jack Kilby, 06270 Villeneuve Loubet. 036 420 040 R.C.S Antibes. Capital de EUR 753.920

-----Original Message-----

From: Roland McGrath [mailto:roland@redhat.com]
Sent: Wednesday, February 23, 2011 3:45 AM
To: Turgis, Frederic
Cc: William Cohen; systemtap@sourceware.org
Subject: RE: interesting option of stap

> I provided you with our Android kernel (arm architecture of course). I checked some other Android kernel, 1 ubuntu kernel and 1 Linaro OMAP kernel, they all have .note.gnu.build-id section at 0 !!
>
> I will have a look at upstream vmlinux.lds.S (and NOTES macro) vs ours.

I looked at git://android.git.kernel.org/kernel/common.git on a guess that it might be an approximate basis for the code you're talking about.

arch/arm/kernel/vmlinux.lds.S there indeed lacks any use of the NOTES macro.  I think the place it probably belongs is before the use of the RO_DATA macro.  I suspect that would make the build ID note come out correctly.  You can look at the output of (eu-)readelf -S on the resultant vmlinux file and that will indicate sufficiently for us to tell how it went.  If you get such a kernel running, you can also look at 'hexdump -C /sys/kernel/notes' to see if the notes got into the kernel properly so they can be interrogated at runtime (this is used by some other tools to locate the debuginfo that goes with the running kernel, though systemtap does not rely on this).


Thanks,
Roland

Re: interesting option of stap

[Frank Ch. Eigler]

f-turgis wrote:

> [...]  Hopefully I already digged some time ago in linker cmd file
> syntax and init call stuff so I am not 100% lost ;-). Here are my
> findings: [...]

Good job.

> - /sys/kernel/notes does not exist on these kernels. I found in all
> my kern els in .zImage.cmd "arm-linux-gnueabi-objcopy ... -R .note
> -R .note.gnu.build-id ... arch/arm/boot/compressed/vmlinux
> arch/arm/boot/zImage", -R being "Remove section xxx from the
> output". That could be why I don't see "notes" in the kernel.

Yes.  Considering how small the .notes* are, it'd be reassuring to
have them be present in the linked image for runtime verification.

> Well, digging further, I simply read again the code and I found:
>   /* Don't save build-id if it is located before _stext.
>    * This probably means that build-id will not be loaded at all and
>    * happens for example with ARM kernel.
>    *
>    * See also:
>    *    http://sources.redhat.com/ml/systemtap/2009-q4/msg00574.html
>    */
>   if (build_id_len > 0 && (build_id_vaddr > base + extra_offset)) {
> [...] commit 66f65c4fb0ddcdf8a85a29662a23a546cfd5dffe [put the test in]
> [...] commit 155bb07a5bfdd16b112870f7064f012970b7fbd9 [took the test out]

OK.  So as a .note-less kernel compatibility measure, a
check-disabling kludge should be put back in, for kernels with a
suspicious build_id_vaddr.

- FChE

RE: interesting option of stap

[Turgis, Frederic]

Hello,

Are you opening the defect yourself ?

By the way, I asked to Linaro guys about ARM .note-less kernel, I will come back to you if I get a good answer

Thanks for your help

Regards
Fred


Frederic Turgis
OMAP Platform Business Unit - OMAP System Engineering - Platform Enablement



Texas Instruments France SA, 821 Avenue Jack Kilby, 06270 Villeneuve Loubet. 036 420 040 R.C.S Antibes. Capital de EUR 753.920

-----Original Message-----

From: Frank Ch. Eigler [mailto:fche@redhat.com]
Sent: Wednesday, February 23, 2011 5:54 PM
To: Turgis, Frederic
Cc: Roland McGrath; William Cohen; systemtap@sourceware.org
Subject: Re: interesting option of stap


f-turgis wrote:

> [...]  Hopefully I already digged some time ago in linker cmd file
> syntax and init call stuff so I am not 100% lost ;-). Here are my
> findings: [...]

Good job.

> - /sys/kernel/notes does not exist on these kernels. I found in all my
> kern els in .zImage.cmd "arm-linux-gnueabi-objcopy ... -R .note -R
> .note.gnu.build-id ... arch/arm/boot/compressed/vmlinux
> arch/arm/boot/zImage", -R being "Remove section xxx from the output".
> That could be why I don't see "notes" in the kernel.

Yes.  Considering how small the .notes* are, it'd be reassuring to have them be present in the linked image for runtime verification.

> Well, digging further, I simply read again the code and I found:
>   /* Don't save build-id if it is located before _stext.
>    * This probably means that build-id will not be loaded at all and
>    * happens for example with ARM kernel.
>    *
>    * See also:
>    *    http://sources.redhat.com/ml/systemtap/2009-q4/msg00574.html
>    */
>   if (build_id_len > 0 && (build_id_vaddr > base + extra_offset)) {
> [...] commit 66f65c4fb0ddcdf8a85a29662a23a546cfd5dffe [put the test
> in] [...] commit 155bb07a5bfdd16b112870f7064f012970b7fbd9 [took the
> test out]

OK.  So as a .note-less kernel compatibility measure, a check-disabling kludge should be put back in, for kernels with a suspicious build_id_vaddr.

- FChE

RE: interesting option of stap

[Turgis, Frederic]

Hi,

Someone from Linaro pointed me to a very recent commit on ARM kernel http://ftp.arm.linux.org.uk/git/gitweb.cgi?p=linux-2.6-arm.git;a=commitdiff;h=dc810efb0ca5702c9d with good comments.

Basically:
- --build-id option has been added in "Makefile" by Roland in 2007. ARM toolchain uses it but places section at 0

- as it was raising issues, problem was worked-around in ARM kernel through options of "objcopy" phase to remove the section. Still vmlinux contains it

- problem was reopened but not closed in 2010

- commit mentioned above uses correct fix:"place correctly notes section in the linker script"
+ the note:"...and to get it exposed as /sys/kernel/notes used by perf tools."

I guess this addresses all our findings.


Regards
Fred


Frederic Turgis
OMAP Platform Business Unit - OMAP System Engineering - Platform Enablement



Texas Instruments France SA, 821 Avenue Jack Kilby, 06270 Villeneuve Loubet. 036 420 040 R.C.S Antibes. Capital de EUR 753.920

-----Original Message-----

From: systemtap-owner@sourceware.org [mailto:systemtap-owner@sourceware.org] On Behalf Of Turgis, Frederic
Sent: Thursday, February 24, 2011 11:43 PM
To: Frank Ch. Eigler
Cc: Roland McGrath; William Cohen; systemtap@sourceware.org
Subject: RE: interesting option of stap

Hello,

Are you opening the defect yourself ?

By the way, I asked to Linaro guys about ARM .note-less kernel, I will come back to you if I get a good answer

Thanks for your help

Regards
Fred


Frederic Turgis
OMAP Platform Business Unit - OMAP System Engineering - Platform Enablement



Texas Instruments France SA, 821 Avenue Jack Kilby, 06270 Villeneuve Loubet. 036 420 040 R.C.S Antibes. Capital de EUR 753.920

-----Original Message-----

From: Frank Ch. Eigler [mailto:fche@redhat.com]
Sent: Wednesday, February 23, 2011 5:54 PM
To: Turgis, Frederic
Cc: Roland McGrath; William Cohen; systemtap@sourceware.org
Subject: Re: interesting option of stap


f-turgis wrote:

> [...]  Hopefully I already digged some time ago in linker cmd file
> syntax and init call stuff so I am not 100% lost ;-). Here are my
> findings: [...]

Good job.

> - /sys/kernel/notes does not exist on these kernels. I found in all my
> kern els in .zImage.cmd "arm-linux-gnueabi-objcopy ... -R .note -R
> .note.gnu.build-id ... arch/arm/boot/compressed/vmlinux
> arch/arm/boot/zImage", -R being "Remove section xxx from the output".
> That could be why I don't see "notes" in the kernel.

Yes.  Considering how small the .notes* are, it'd be reassuring to have them be present in the linked image for runtime verification.

> Well, digging further, I simply read again the code and I found:
>   /* Don't save build-id if it is located before _stext.
>    * This probably means that build-id will not be loaded at all and
>    * happens for example with ARM kernel.
>    *
>    * See also:
>    *    http://sources.redhat.com/ml/systemtap/2009-q4/msg00574.html
>    */
>   if (build_id_len > 0 && (build_id_vaddr > base + extra_offset)) {
> [...] commit 66f65c4fb0ddcdf8a85a29662a23a546cfd5dffe [put the test
> in] [...] commit 155bb07a5bfdd16b112870f7064f012970b7fbd9 [took the
> test out]

OK.  So as a .note-less kernel compatibility measure, a check-disabling kludge should be put back in, for kernels with a suspicious build_id_vaddr.

- FChE

RE: interesting option of stap

[Roland McGrath]

> Someone from Linaro pointed me to a very recent commit on ARM kernel http://ftp.arm.linux.org.uk/git/gitweb.cgi?p=linux-2.6-arm.git;a=commitdiff;h=dc810efb0ca5702c9d with good comments.

I mentioned before that the mainline arm code has this.  Note that, as I
mentioned before, it is not really placed where it should be--it will be
writable when it should be rodata.  (The sample comment in vmlinux.lds.h
puts RO_DATA, EXCEPTION_TABLE, and NOTES all in stupid places not matching
where canonical cases like x86 actually put them.)  Though it's not a wise
placement and IMHO ought it to be fixed, it should work fine as it is.


Thanks,
Roland

RE: interesting option of stap

[Turgis, Frederic]

Right, my bad. I think I read your previous mail too fast like "In recent upstream kernel sources, arch/arm/kernel/vmlinux.lds.S should use the NOTES macro..." whereas you stated "uses". Well, it was past midnight for me :-(

I'll try to follow-up in Linaro if I get reasons why it is placed there. I guess that closes the topic ;-)


Regards
Fred


Frederic Turgis
OMAP Platform Business Unit - OMAP System Engineering - Platform Enablement



Texas Instruments France SA, 821 Avenue Jack Kilby, 06270 Villeneuve Loubet. 036 420 040 R.C.S Antibes. Capital de EUR 753.920

-----Original Message-----

From: Roland McGrath [mailto:roland@redhat.com]
Sent: Friday, February 25, 2011 6:24 PM
To: Turgis, Frederic
Cc: Frank Ch. Eigler; William Cohen; systemtap@sourceware.org
Subject: RE: interesting option of stap

> Someone from Linaro pointed me to a very recent commit on ARM kernel http://ftp.arm.linux.org.uk/git/gitweb.cgi?p=linux-2.6-arm.git;a=commitdiff;h=dc810efb0ca5702c9d with good comments.

I mentioned before that the mainline arm code has this.  Note that, as I mentioned before, it is not really placed where it should be--it will be writable when it should be rodata.  (The sample comment in vmlinux.lds.h puts RO_DATA, EXCEPTION_TABLE, and NOTES all in stupid places not matching where canonical cases like x86 actually put them.)  Though it's not a wise placement and IMHO ought it to be fixed, it should work fine as it is.


Thanks,
Roland