Re: Prelinking on ARM with Debug Link

Re: Prelinking on ARM with Debug Link

[Torsten Polle]

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

Hi Mark,
 
Now with attachment.

> Torsten Polle writes
>
> Hi Mark,
>
> Mark Wielaard writes:
>> On Fri, Nov 27, 2015 at 04:06:14PM +0100, Mark Wielaard wrote:
>>> On Fri, Nov 27, 2015 at 01:57:31PM +0100, Torsten Polle wrote:
>>> > In file included from /tmp/stap/taptrek_src.c:6010:0:
>>> > /tmp/stap/stap-symbols.h:95902:1: error: large integer implicitly truncated to unsigned type [-Werror=overflow]
>>>
>>> But the stap-symbols.h file has only 8107 lines.
>
>> If you happen to know which library it is that causes the issue, then
>> it would be beneficial to also have the output of eu-readelf -Sl for
>> both the main and debug file.
>
>> And maybe the stap -vv output of the script to know which files and
>> probes are used.
>
>> Thanks,
>> Mark
>
> thanks for the support.
>
> I'll provide you with a reproduction scenario that is much smaller.
>
> Kind Regards,
> Torsten

Please find a less complex example attached.

The output of readelf -Sl for the affected library.
libc-2.18.so.txt

The library is using a debug link to link to a file with the debug information.
libc-2.18.so.debug.txt

The command to run the script "taptrek_run_ZIX2.stp" is stored in "cmd.sh".

The output of executing "cmd.sh" is in "cmd-output.txt".

The folder "stap" contains the result of the stap run. I only removed
the already compiled object files to keep the size small.

Thanks,
Torsten

[-- Attachment #2: prelinking.tar.bz2 --]
[-- Type: application/x-bzip2, Size: 63461 bytes --]

Re: Prelinking on ARM with Debug Link

[Torsten Polle]

Hi Mark,

I’ve not received any answer on my posting. So I wonder whether the mail might have slipped your attention or there is any other information you might need.

> Am 01.12.2015 um 20:29 schrieb Torsten Polle <Torsten.Polle@gmx.de>:
> 
> Hi Mark,
> 
> Now with attachment.
> 
>> Torsten Polle writes
>> 
>> Hi Mark,
>> 
>> Mark Wielaard writes:
>>> On Fri, Nov 27, 2015 at 04:06:14PM +0100, Mark Wielaard wrote:
>>>> On Fri, Nov 27, 2015 at 01:57:31PM +0100, Torsten Polle wrote:
>>>>> In file included from /tmp/stap/taptrek_src.c:6010:0:
>>>>> /tmp/stap/stap-symbols.h:95902:1: error: large integer implicitly truncated to unsigned type [-Werror=overflow]
>>>> 
>>>> But the stap-symbols.h file has only 8107 lines.
>> 
>>> If you happen to know which library it is that causes the issue, then
>>> it would be beneficial to also have the output of eu-readelf -Sl for
>>> both the main and debug file.
>> 
>>> And maybe the stap -vv output of the script to know which files and
>>> probes are used.
>> 
>>> Thanks,
>>> Mark
>> 
>> thanks for the support.
>> 
>> I'll provide you with a reproduction scenario that is much smaller.
>> 
>> Kind Regards,
>> Torsten
> 
> Please find a less complex example attached.
> 
> The output of readelf -Sl for the affected library.
> libc-2.18.so.txt
> 
> The library is using a debug link to link to a file with the debug information.
> libc-2.18.so.debug.txt
> 
> The command to run the script "taptrek_run_ZIX2.stp" is stored in "cmd.sh".
> 
> The output of executing "cmd.sh" is in "cmd-output.txt".
> 
> The folder "stap" contains the result of the stap run. I only removed
> the already compiled object files to keep the size small.
> 
> Thanks,
> Torsten
> <prelinking.tar.bz2>

Thanks,
Torsten

Re: Prelinking on ARM with Debug Link

[Mark Wielaard]

Hi Torsten,

On Tue, 2016-02-09 at 21:55 +0100, Torsten Polle wrote:
> I’ve not received any answer on my posting. So I wonder whether the
> mail might have slipped your attention or there is any other
> information you might need.

Sorry, I forgot about this issue.

It has been some time since I hacked on this code, so I don't
immediately know what is going on. It would be nice to have a somewhat
simpler reproducer. You use a large stap script using guru mode mixing
user and kernel probes. Is all that really necessary to replicate the
issue? Is the issue only triggered by the cross compiling?

It seems the issue is this generated code from stap-symbols.h
for /lib/libc-2.18.so:

static struct _stp_section _stp_module_1_sections[] = {
{
.name = ".dynamic",
.size = 0x13b9e8,
.symbols = _stp_module_1_symbols_0,
.num_symbols = 0,
#if defined(STP_USE_DWARF_UNWINDER) && defined(STP_NEED_UNWIND_DATA)
.debug_hdr = _stp_module_1_debug_frame_hdr_0,
.debug_hdr_len = 22604, 
.sec_load_offset = 0xffffffffffffebc0
#else
.debug_hdr = NULL,
.debug_hdr_len = 0,
.sec_load_offset = 0
#endif /* STP_USE_DWARF_UNWINDER && STP_NEED_UNWIND_DATA */
},
};

The .sec_load_offset went negative and produced a large hex output that
doesn't fit. We'll have to find out if the issue is that the value
became negative. Or whether the issue is that the generated value is too
big for the (cross-compiled) field type. Or maybe both.

Cheers,

mark

Re: Prelinking on ARM with Debug Link

[Torsten Polle]

Hi Mark,

Thanks for the answer.

> Am 10.02.2016 um 17:17 schrieb Mark Wielaard <mjw@redhat.com>:
> 
> Hi Torsten,
> 
> On Tue, 2016-02-09 at 21:55 +0100, Torsten Polle wrote:
>> I’ve not received any answer on my posting. So I wonder whether the
>> mail might have slipped your attention or there is any other
>> information you might need.
> 
> Sorry, I forgot about this issue.
> 
> It has been some time since I hacked on this code, so I don't
> immediately know what is going on. It would be nice to have a somewhat
> simpler reproducer. You use a large stap script using guru mode mixing
> user and kernel probes. Is all that really necessary to replicate the
> issue? Is the issue only triggered by the cross compiling?

Do you mean the example in my original mail or do you refer to the much simpler example from [1]?

> It seems the issue is this generated code from stap-symbols.h
> for /lib/libc-2.18.so:
> 
> static struct _stp_section _stp_module_1_sections[] = {
> {
> .name = ".dynamic",
> .size = 0x13b9e8,
> .symbols = _stp_module_1_symbols_0,
> .num_symbols = 0,
> #if defined(STP_USE_DWARF_UNWINDER) && defined(STP_NEED_UNWIND_DATA)
> .debug_hdr = _stp_module_1_debug_frame_hdr_0,
> .debug_hdr_len = 22604, 
> .sec_load_offset = 0xffffffffffffebc0
> #else
> .debug_hdr = NULL,
> .debug_hdr_len = 0,
> .sec_load_offset = 0
> #endif /* STP_USE_DWARF_UNWINDER && STP_NEED_UNWIND_DATA */
> },
> };
> 
> The .sec_load_offset went negative and produced a large hex output that
> doesn't fit. We'll have to find out if the issue is that the value
> became negative. Or whether the issue is that the generated value is too
> big for the (cross-compiled) field type. Or maybe both.

I made some feeble attempts to fix this issue, i.e. I tried to figure out whether the negative offset made any sense at all. But all attempts on my part failed so far. So any help is much appreciated.

> Cheers,
> 
> mark

Thanks,
Torsten

[1] https://sourceware.org/ml/systemtap/2015-q4/msg00219.html

Re: Prelinking on ARM with Debug Link

[Mark Wielaard]

On Wed, 2016-02-10 at 21:12 +0100, Torsten Polle wrote:
> > Am 10.02.2016 um 17:17 schrieb Mark Wielaard <mjw@redhat.com>:
> > It has been some time since I hacked on this code, so I don't
> > immediately know what is going on. It would be nice to have a somewhat
> > simpler reproducer. You use a large stap script using guru mode mixing
> > user and kernel probes. Is all that really necessary to replicate the
> > issue? Is the issue only triggered by the cross compiling?
> 
> Do you mean the example in my original mail or do you refer to the much simpler example from [1]?

Maybe I am not reading the simpler example correctly.
But it looked like it was still mixing user and kernel probes, used guru
mode and cross compiling. Are all of those factors needed to trigger the
bug?

If at all possible just one simple probe against libc.so to show what is
going wrong would be ideal.

Thanks,

Mark

Aw: Re: Prelinking on ARM with Debug Link

[Torsten Polle]

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

> Gesendet: Mittwoch, 10. Februar 2016 um 21:35 Uhr
> Von: "Mark Wielaard" <mjw@redhat.com>
> An: "Torsten Polle" <Torsten.Polle@gmx.de>
> Cc: systemtap@sourceware.org
> Betreff: Re: Prelinking on ARM with Debug Link
> On Wed, 2016-02-10 at 21:12 +0100, Torsten Polle wrote:
> > > Am 10.02.2016 um 17:17 schrieb Mark Wielaard <mjw@redhat.com>:
> > > It has been some time since I hacked on this code, so I don't
> > > immediately know what is going on. It would be nice to have a somewhat
> > > simpler reproducer. You use a large stap script using guru mode mixing
> > > user and kernel probes. Is all that really necessary to replicate the
> > > issue? Is the issue only triggered by the cross compiling?
> >
> > Do you mean the example in my original mail or do you refer to the much simpler example from [1]?
> 
> Maybe I am not reading the simpler example correctly.
> But it looked like it was still mixing user and kernel probes, used guru
> mode and cross compiling. Are all of those factors needed to trigger the
> bug?
> 
> If at all possible just one simple probe against libc.so to show what is
> going wrong would be ideal.

Dear Mark,
 
Please find a simplified example attached. It's not the probe itself but rather
the fact that I include unwind information for libc-2.18.so.

I also found another combination that triggers the error. If the script looks as follows

probe never
{
	print_ubacktrace();
}

probe process("/lib/libc-2.18.so").function("__libc_malloc@/opt/codesourcery/arm-none-linux-gnueabi/src/glibc/malloc/malloc.c").call
{
    printf("call\n");
}
probe process("/lib/libc-2.18.so").function("__libc_malloc@/opt/codesourcery/arm-none-linux-gnueabi/src/glibc/malloc/malloc.c").return
{
    printf("return\n");
}

I don't need the -d option.

> Thanks,
> 
> Mark

Kind Regards,
Torsten

[-- Attachment #2: prelinking.tar.bz2 --]
[-- Type: application/octet-stream, Size: 223744 bytes --]

Re: Aw: Re: Prelinking on ARM with Debug Link

[Mark Wielaard]

On Thu, 2016-02-11 at 11:49 +0100, Torsten Polle wrote:
> > On Wed, 2016-02-10 at 21:12 +0100, Torsten Polle wrote:
> > > > Am 10.02.2016 um 17:17 schrieb Mark Wielaard <mjw@redhat.com>:
> > Maybe I am not reading the simpler example correctly.
> > But it looked like it was still mixing user and kernel probes, used guru
> > mode and cross compiling. Are all of those factors needed to trigger the
> > bug?
> > 
> > If at all possible just one simple probe against libc.so to show what is
> > going wrong would be ideal.
>  
> Please find a simplified example attached. It's not the probe itself but rather
> the fact that I include unwind information for libc-2.18.so.
> 
> I also found another combination that triggers the error. If the script looks as follows
> 
> probe never
> {
> 	print_ubacktrace();
> }
> 
> probe process("/lib/libc-2.18.so").function("__libc_malloc@/opt/codesourcery/arm-none-linux-gnueabi/src/glibc/malloc/malloc.c").call
> {
>     printf("call\n");
> }
> probe process("/lib/libc-2.18.so").function("__libc_malloc@/opt/codesourcery/arm-none-linux-gnueabi/src/glibc/malloc/malloc.c").return
> {
>     printf("return\n");
> }
> 
> I don't need the -d option.

OK. Which other options are necessary?
In particular in your cmd.sh you seem to be using -a arm -B
CROSS_COMPILE=arm-none-linux-gnueabi- and -B CONFIG_DEBUG_INFO=y
Is there a reason to use those options to reproduce the issue? I am
particularly trying to figure out if you need or are using a cross build
and if so between which architectures.

Thanks,

Mark

Re: Prelinking on ARM with Debug Link

[Torsten Polle]

> Am 16.02.2016 um 11:08 schrieb Mark Wielaard <mjw@redhat.com>:
> 
> OK. Which other options are necessary?
> In particular in your cmd.sh you seem to be using -a arm -B
> CROSS_COMPILE=arm-none-linux-gnueabi- and -B CONFIG_DEBUG_INFO=y
> Is there a reason to use those options to reproduce the issue? I am
> particularly trying to figure out if you need or are using a cross build
> and if so between which architectures.
> 
> Thanks,
> 
> Mark

Hi Mark,

I’ve a cross compile environment.

-a arm is necessary to choose the right architecture.
-B CROSS_COMPILE=arm-none-linux-gnueabi- sets the compiler prefix for the Linux kernel compilation.

-B CONFIG_DEBUG_INFO=y is not necessary.

The target architecture is 32bit ARM. The host architecture is 64bit X86. That’s the reason why field .sec_load_offset is initialised with a 64bit wide hexadecimal number. But as the field .sec_load_offset is defined only as „unsigned long“, the compiler complains. As a work around I tried to output decimal number instead for the initialisation of .sec_load_offset. I can compile alright. But the resulting backtrace calculations shown in my previous example produce strange results.

Kind Regards,
Torsten

Re: Prelinking on ARM with Debug Link

[Mark Wielaard]

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

On Tue, 2016-02-16 at 21:46 +0100, Torsten Polle wrote:
> The target architecture is 32bit ARM. The host architecture is 64bit
> X86. That’s the reason why field .sec_load_offset is initialised with
> a 64bit wide hexadecimal number. But as the field .sec_load_offset is
> defined only as „unsigned long“, the compiler complains. As a work
> around I tried to output decimal number instead for the initialisation
> of .sec_load_offset. I can compile alright. But the resulting
> backtrace calculations shown in my previous example produce strange
> results.

OK, I don't have such a setup, but maybe all that is needed, if we
assume negative values are ok, is to not write sec_load_offset out in
hex, but simply in dec. Could you try the attached patch?

Thanks,

Mark

[-- Attachment #2: sec_load_offset.patch --]
[-- Type: text/x-patch, Size: 1247 bytes --]

diff --git a/translate.cxx b/translate.cxx
index f792343..1874163 100644
--- a/translate.cxx
+++ b/translate.cxx
@@ -6845,8 +6845,10 @@ dump_unwindsym_cxt (Dwfl_Module *m,
 
 	  Dwarf_Addr dwbias = 0;
 	  dwfl_module_getdwarf (m, &dwbias);
-	  c->output << ".sec_load_offset = 0x"
-		    << hex << debug_frame_off - dwbias << dec << "\n";
+	  /* Note we use dec, not hex, in case host width > target width
+	     and offset is negative.  */
+	  c->output << ".sec_load_offset = "
+		    << debug_frame_off - dwbias << "\n";
 
 	  c->output << "#else\n";
 	  c->output << ".debug_hdr = NULL,\n";
@@ -6865,8 +6867,10 @@ dump_unwindsym_cxt (Dwfl_Module *m,
               c->output << "#if defined(STP_NEED_LINE_DATA)\n";
               Dwarf_Addr dwbias = 0;
               dwfl_module_getdwarf (m, &dwbias);
-              c->output << ".sec_load_offset = 0x"
-                        << hex << debug_frame_off - dwbias << dec << "\n";
+	      /* Note we use dec, not hex, in case host width > target width
+		 and offset is negative.  */
+              c->output << ".sec_load_offset = "
+                        << debug_frame_off - dwbias << "\n";
               c->output << "#else\n";
             }
 	  c->output << ".sec_load_offset = 0\n";

Re: Prelinking on ARM with Debug Link

[Torsten Polle]

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

Am 18.02.2016 um 17:21 schrieb Mark Wielaard <mjw@redhat.com>:
> 
> On Tue, 2016-02-16 at 21:46 +0100, Torsten Polle wrote:
>> The target architecture is 32bit ARM. The host architecture is 64bit
>> X86. That’s the reason why field .sec_load_offset is initialised with
>> a 64bit wide hexadecimal number. But as the field .sec_load_offset is
>> defined only as „unsigned long“, the compiler complains. As a work
>> around I tried to output decimal number instead for the initialisation
>> of .sec_load_offset. I can compile alright. But the resulting
>> backtrace calculations shown in my previous example produce strange
>> results.
> 
> OK, I don't have such a setup, but maybe all that is needed, if we
> assume negative values are ok, is to not write sec_load_offset out in
> hex, but simply in dec. Could you try the attached patch?
> 
> Thanks,
> 
> Mark

Hi Mark,

the principle idea of your patch works. But I had to rewrite it to really work in my environment. Could you please have a look at my proposal? Would something like that be acceptable?

I would like to double check in my environment if we could fall back to the hex notation again.

Thanks,
Torsten

[-- Attachment #2: 0001-Fix-Compilation-fails-for-prelinked-libraries.patch --]
[-- Type: application/octet-stream, Size: 3013 bytes --]

From c2854c6c8400ae3658e6037d2a0bc656ee550a33 Mon Sep 17 00:00:00 2001
Message-Id: <c2854c6c8400ae3658e6037d2a0bc656ee550a33.1456177234.git.Torsten.Polle@gmx.de>
From: Torsten Polle <Torsten.Polle@gmx.de>
Date: Mon, 22 Feb 2016 22:39:59 +0100
Subject: [PATCH] Fix: Compilation fails for prelinked libraries.

The offset to the section ".text" in a prelinked library might increase due to
changed relocations that need more space. If the prelinked library contains a
debug link and the linked file is not prelinked, the offset to the ".text"
section is different. If the difference between the offset of the ".text"
section in the prelinked library and non-prelinked library (with e.g. debug
information) becomes negative, the representation of this negative number has
to fit into an "unsigned int". If the width of the host is larger than the
width of the target, the compilation for the target fails.

Signed-off-by: Torsten Polle <Torsten.Polle@gmx.de>
---
 translate.cxx |   34 ++++++++++++++++++++++++++++++----
 1 files changed, 30 insertions(+), 4 deletions(-)

diff --git a/translate.cxx b/translate.cxx
index f792343..f0364e9 100644
--- a/translate.cxx
+++ b/translate.cxx
@@ -6844,9 +6844,22 @@ dump_unwindsym_cxt (Dwfl_Module *m,
           c->output << ".debug_hdr_len = " << debug_frame_hdr_len << ", \n";
 
 	  Dwarf_Addr dwbias = 0;
+	  Dwarf_Addr elf_bias;
+	  GElf_Ehdr *ehdr, ehdr_mem;
+	  Elf *elf;
+	  elf = dwfl_module_getelf(m, &elf_bias);
+	  ehdr = gelf_getehdr(elf, &ehdr_mem);
 	  dwfl_module_getdwarf (m, &dwbias);
-	  c->output << ".sec_load_offset = 0x"
-		    << hex << debug_frame_off - dwbias << dec << "\n";
+	  if (ehdr->e_ident[EI_CLASS] == ELFCLASS32)
+	    {
+	      c->output << ".sec_load_offset = "
+			<< (uint32_t)debug_frame_off - (uint32_t)dwbias << "u\n";
+	    }
+	  else
+	    {
+	      c->output << ".sec_load_offset = 0x"
+			<< hex << debug_frame_off - dwbias << dec << "\n";
+	    }
 
 	  c->output << "#else\n";
 	  c->output << ".debug_hdr = NULL,\n";
@@ -6864,9 +6877,22 @@ dump_unwindsym_cxt (Dwfl_Module *m,
             {
               c->output << "#if defined(STP_NEED_LINE_DATA)\n";
               Dwarf_Addr dwbias = 0;
+	      Dwarf_Addr elf_bias;
+	      GElf_Ehdr *ehdr, ehdr_mem;
+	      Elf *elf;
+	      elf = dwfl_module_getelf(m, &elf_bias);
+	      ehdr = gelf_getehdr(elf, &ehdr_mem);
               dwfl_module_getdwarf (m, &dwbias);
-              c->output << ".sec_load_offset = 0x"
-                        << hex << debug_frame_off - dwbias << dec << "\n";
+	      if (ehdr->e_ident[EI_CLASS] == ELFCLASS32)
+		{
+		  c->output << ".sec_load_offset = "
+			    << (uint32_t)debug_frame_off - (uint32_t)dwbias << "u\n";
+		}
+	      else
+		{
+		  c->output << ".sec_load_offset = 0x"
+			    << hex << debug_frame_off - dwbias << dec << "\n";
+		}
               c->output << "#else\n";
             }
 	  c->output << ".sec_load_offset = 0\n";
-- 
1.7.4.1

Re: Prelinking on ARM with Debug Link

[Mark Wielaard]

On Mon, 2016-02-22 at 22:45 +0100, Torsten Polle wrote:
> the principle idea of your patch works. But I had to rewrite it to
> really work in my environment. Could you please have a look at my
> proposal? Would something like that be acceptable?

Could you give an example of what didn't work?
You cast both debug_frame_off and dwbias to uint32_t before
substracting. Is that really necessary/correct? Both are Dwarf_Addrs
which are always uint64_t. And we care about the difference here.

> I would like to double check in my environment if we could fall back to the hex notation again.

Isn't it simpler and consistent to just always use decimal in this case?
There should at least be a comment why we use a different notation for
elf32 vs elf64 targets.

Thanks,

Mark

Re: Prelinking on ARM with Debug Link

[Torsten Polle]

> Am 23.02.2016 um 17:46 schrieb Mark Wielaard <mjw@redhat.com>:
> 
> On Mon, 2016-02-22 at 22:45 +0100, Torsten Polle wrote:
>> the principle idea of your patch works. But I had to rewrite it to
>> really work in my environment. Could you please have a look at my
>> proposal? Would something like that be acceptable?
> 
> Could you give an example of what didn't work?
> You cast both debug_frame_off and dwbias to uint32_t before
> substracting. Is that really necessary/correct? Both are Dwarf_Addrs
> which are always uint64_t. And we care about the difference here.

In my case debug_frame_off is larger than dwbias. If for instance debug_frame_off is 0 and dwbias is -1, the result is -1. As the arithmethics on the 64bit host is unsigned, the result is 0xffffffffffffffff in hex notation and 18446744073709551615 in decimal notation. As stap-symbols.h is used for the target, the values are too large for the 32bit wide unsigned int, which is the data type for the field sec_load_offset. Therefore the compiler complains. The type cast to uint32_t forces the host compiler to use only a 32bit value. Therefore the result is 0xffffffff (4294967295). At least that is what happens on my host. I need the „u“ because even 4294967295 is considered to be too large.

>> I would like to double check in my environment if we could fall back to the hex notation again.
> 
> Isn't it simpler and consistent to just always use decimal in this case?
> There should at least be a comment why we use a different notation for
> elf32 vs elf64 targets.

I would go for a consistent notation. Personally, I prefer the hex notation for the addresses. I hope to be able to check whether the hex notation with casts works tomorrow and get back to you.

Regards,
Torsten

Re: Prelinking on ARM with Debug Link

[Torsten Polle]

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


> Am 23.02.2016 um 23:16 schrieb Torsten Polle <Torsten.Polle@gmx.de>:
> 
> 
>> Am 23.02.2016 um 17:46 schrieb Mark Wielaard <mjw@redhat.com>:
>> 
>> On Mon, 2016-02-22 at 22:45 +0100, Torsten Polle wrote:
>>> the principle idea of your patch works. But I had to rewrite it to
>>> really work in my environment. Could you please have a look at my
>>> proposal? Would something like that be acceptable?
>> 
>> Could you give an example of what didn't work?
>> You cast both debug_frame_off and dwbias to uint32_t before
>> substracting. Is that really necessary/correct? Both are Dwarf_Addrs
>> which are always uint64_t. And we care about the difference here.
> 
> In my case debug_frame_off is larger than dwbias. If for instance debug_frame_off is 0 and dwbias is -1, the result is -1. As the arithmethics on the 64bit host is unsigned, the result is 0xffffffffffffffff in hex notation and 18446744073709551615 in decimal notation. As stap-symbols.h is used for the target, the values are too large for the 32bit wide unsigned int, which is the data type for the field sec_load_offset. Therefore the compiler complains. The type cast to uint32_t forces the host compiler to use only a 32bit value. Therefore the result is 0xffffffff (4294967295). At least that is what happens on my host. I need the „u“ because even 4294967295 is considered to be too large.
> 
>>> I would like to double check in my environment if we could fall back to the hex notation again.
>> 
>> Isn't it simpler and consistent to just always use decimal in this case?
>> There should at least be a comment why we use a different notation for
>> elf32 vs elf64 targets.
> 
> I would go for a consistent notation. Personally, I prefer the hex notation for the addresses. I hope to be able to check whether the hex notation with casts works tomorrow and get back to you.
> 
> Regards,
> Torsten

Mark,

Please find a new version of the patch attached. I changed the patch to use hexadecimal numbers consistently.

Kind Regards,
Torsten

[-- Attachment #2: 0001-PATCH-v2-Fix-Compilation-fails-for-prelinked-librari.patch --]
[-- Type: application/octet-stream, Size: 3100 bytes --]

From 215d886c44bc4e2411082cb7636d12284e334897 Mon Sep 17 00:00:00 2001
Message-Id: <215d886c44bc4e2411082cb7636d12284e334897.1456692346.git.Torsten.Polle@gmx.de>
From: Torsten Polle <Torsten.Polle@gmx.de>
Date: Sun, 28 Feb 2016 21:45:33 +0100
Subject: [PATCH] [PATCH v2] Fix: Compilation fails for prelinked libraries.

The offset to the section ".text" in a prelinked library might increase due to
changed relocations that need more space. If the prelinked library contains a
debug link and the linked file is not prelinked, the offset to the ".text"
section is different. If the difference between the offset of the ".text"
section in the prelinked library and non-prelinked library (with e.g. debug
information) becomes negative, the representation of this negative number has
to fit into an uint32_t. If the width of the host is larger than the
width of the target, the (cross-) compilation for the target fails.

Changes since v1:
* Use hex values for the 32bit case.

Signed-off-by: Torsten Polle <Torsten.Polle@gmx.de>
---
 translate.cxx |   34 ++++++++++++++++++++++++++++++----
 1 files changed, 30 insertions(+), 4 deletions(-)

diff --git a/translate.cxx b/translate.cxx
index f792343..56d23e8 100644
--- a/translate.cxx
+++ b/translate.cxx
@@ -6844,9 +6844,22 @@ dump_unwindsym_cxt (Dwfl_Module *m,
           c->output << ".debug_hdr_len = " << debug_frame_hdr_len << ", \n";
 
 	  Dwarf_Addr dwbias = 0;
+	  Dwarf_Addr elf_bias;
+	  GElf_Ehdr *ehdr, ehdr_mem;
+	  Elf *elf;
+	  elf = dwfl_module_getelf(m, &elf_bias);
+	  ehdr = gelf_getehdr(elf, &ehdr_mem);
 	  dwfl_module_getdwarf (m, &dwbias);
-	  c->output << ".sec_load_offset = 0x"
-		    << hex << debug_frame_off - dwbias << dec << "\n";
+	  if (ehdr->e_ident[EI_CLASS] == ELFCLASS32)
+	    {
+	      c->output << ".sec_load_offset = 0x"
+			<< hex << (uint32_t)(debug_frame_off - dwbias) << dec << "\n";
+	    }
+	  else
+	    {
+	      c->output << ".sec_load_offset = 0x"
+			<< hex << debug_frame_off - dwbias << dec << "\n";
+	    }
 
 	  c->output << "#else\n";
 	  c->output << ".debug_hdr = NULL,\n";
@@ -6864,9 +6877,22 @@ dump_unwindsym_cxt (Dwfl_Module *m,
             {
               c->output << "#if defined(STP_NEED_LINE_DATA)\n";
               Dwarf_Addr dwbias = 0;
+	      Dwarf_Addr elf_bias;
+	      GElf_Ehdr *ehdr, ehdr_mem;
+	      Elf *elf;
+	      elf = dwfl_module_getelf(m, &elf_bias);
+	      ehdr = gelf_getehdr(elf, &ehdr_mem);
               dwfl_module_getdwarf (m, &dwbias);
-              c->output << ".sec_load_offset = 0x"
-                        << hex << debug_frame_off - dwbias << dec << "\n";
+	      if (ehdr->e_ident[EI_CLASS] == ELFCLASS32)
+		{
+		  c->output << ".sec_load_offset = 0x"
+			    << hex << (uint32_t)(debug_frame_off - dwbias) << dec << "\n";
+		}
+	      else
+		{
+		  c->output << ".sec_load_offset = 0x"
+			    << hex << debug_frame_off - dwbias << dec << "\n";
+		}
               c->output << "#else\n";
             }
 	  c->output << ".sec_load_offset = 0\n";
-- 
1.7.4.1

Re: Prelinking on ARM with Debug Link

[Torsten Polle]

> Am 28.02.2016 um 21:51 schrieb Torsten Polle <Torsten.Polle@gmx.de>:
> 
> 
>> Am 23.02.2016 um 23:16 schrieb Torsten Polle <Torsten.Polle@gmx.de>:
>> 
>> 
>>> Am 23.02.2016 um 17:46 schrieb Mark Wielaard <mjw@redhat.com>:
>>> 
>>> On Mon, 2016-02-22 at 22:45 +0100, Torsten Polle wrote:
>>>> the principle idea of your patch works. But I had to rewrite it to
>>>> really work in my environment. Could you please have a look at my
>>>> proposal? Would something like that be acceptable?
>>> 
>>> Could you give an example of what didn't work?
>>> You cast both debug_frame_off and dwbias to uint32_t before
>>> substracting. Is that really necessary/correct? Both are Dwarf_Addrs
>>> which are always uint64_t. And we care about the difference here.
>> 
>> In my case debug_frame_off is larger than dwbias. If for instance debug_frame_off is 0 and dwbias is -1, the result is -1. As the arithmethics on the 64bit host is unsigned, the result is 0xffffffffffffffff in hex notation and 18446744073709551615 in decimal notation. As stap-symbols.h is used for the target, the values are too large for the 32bit wide unsigned int, which is the data type for the field sec_load_offset. Therefore the compiler complains. The type cast to uint32_t forces the host compiler to use only a 32bit value. Therefore the result is 0xffffffff (4294967295). At least that is what happens on my host. I need the „u“ because even 4294967295 is considered to be too large.
>> 
>>>> I would like to double check in my environment if we could fall back to the hex notation again.
>>> 
>>> Isn't it simpler and consistent to just always use decimal in this case?
>>> There should at least be a comment why we use a different notation for
>>> elf32 vs elf64 targets.
>> 
>> I would go for a consistent notation. Personally, I prefer the hex notation for the addresses. I hope to be able to check whether the hex notation with casts works tomorrow and get back to you.
>> 
>> Regards,
>> Torsten
> 
> Mark,
> 
> Please find a new version of the patch attached. I changed the patch to use hexadecimal numbers consistently.
> 
> Kind Regards,
> Torsten
> <0001-PATCH-v2-Fix-Compilation-fails-for-prelinked-librari.patch>

Mark,

any comments or thoughts on my proposal?

Kind Regards,
Torsten

Re: Prelinking on ARM with Debug Link

[Mark Wielaard]

Hi Torsten,

On Wed, 2016-03-30 at 22:05 +0200, Torsten Polle wrote:
> > Am 28.02.2016 um 21:51 schrieb Torsten Polle <Torsten.Polle@gmx.de>: 
> >> Am 23.02.2016 um 23:16 schrieb Torsten Polle <Torsten.Polle@gmx.de>:
> >>> Am 23.02.2016 um 17:46 schrieb Mark Wielaard <mjw@redhat.com>:
> >>> 
> >>> On Mon, 2016-02-22 at 22:45 +0100, Torsten Polle wrote:
> >>>> the principle idea of your patch works. But I had to rewrite it to
> >>>> really work in my environment. Could you please have a look at my
> >>>> proposal? Would something like that be acceptable?
> >>> 
> >>> Could you give an example of what didn't work?
> >>> You cast both debug_frame_off and dwbias to uint32_t before
> >>> substracting. Is that really necessary/correct? Both are Dwarf_Addrs
> >>> which are always uint64_t. And we care about the difference here.
> >> 
> >> In my case debug_frame_off is larger than dwbias. If for instance debug_frame_off is 0 and dwbias is -1, the result is -1. As the arithmethics on the 64bit host is unsigned, the result is 0xffffffffffffffff in hex notation and 18446744073709551615 in decimal notation. As stap-symbols.h is used for the target, the values are too large for the 32bit wide unsigned int, which is the data type for the field sec_load_offset. Therefore the compiler complains. The type cast to uint32_t forces the host compiler to use only a 32bit value. Therefore the result is 0xffffffff (4294967295). At least that is what happens on my host. I need the „u“ because even 4294967295 is considered to be too large.
> >> 
> >>>> I would like to double check in my environment if we could fall back to the hex notation again.
> >>> 
> >>> Isn't it simpler and consistent to just always use decimal in this case?
> >>> There should at least be a comment why we use a different notation for
> >>> elf32 vs elf64 targets.
> >> 
> >> I would go for a consistent notation. Personally, I prefer the hex notation for the addresses. I hope to be able to check whether the hex notation with casts works tomorrow and get back to you.
>
> > Please find a new version of the patch attached. I changed the patch to use hexadecimal numbers consistently.
> > 
> > Kind Regards,
> > Torsten
> > <0001-PATCH-v2-Fix-Compilation-fails-for-prelinked-librari.patch>
>
> any comments or thoughts on my proposal?

Sorry I had forgotten about this issue.
In your example you have a debug_frame_off with zero and a dwbias of -1.
That looks somewhat suspicious. Are we sure that isn't a special case?

A debug_frame_off of zero seems to indicate that there isn't a
debug_frame in the first place. dwbias being -1 might indicate that
dwfl_module_getdwarf () failed. We don't seem to check whether the call
succeeds.

Could you try and see if any of the above is the case in your situation?

Thanks,

Mark

Re: Prelinking on ARM with Debug Link

[Torsten Polle]

> Am 01.04.2016 um 15:07 schrieb Mark Wielaard <mjw@redhat.com>:
> 
> Hi Torsten,
> 
> On Wed, 2016-03-30 at 22:05 +0200, Torsten Polle wrote:
>>> Am 28.02.2016 um 21:51 schrieb Torsten Polle <Torsten.Polle@gmx.de>: 
>>>> Am 23.02.2016 um 23:16 schrieb Torsten Polle <Torsten.Polle@gmx.de>:
>>>>> Am 23.02.2016 um 17:46 schrieb Mark Wielaard <mjw@redhat.com>:
>>>>> 
>>>>> On Mon, 2016-02-22 at 22:45 +0100, Torsten Polle wrote:
>>>>>> the principle idea of your patch works. But I had to rewrite it to
>>>>>> really work in my environment. Could you please have a look at my
>>>>>> proposal? Would something like that be acceptable?
>>>>> 
>>>>> Could you give an example of what didn't work?
>>>>> You cast both debug_frame_off and dwbias to uint32_t before
>>>>> substracting. Is that really necessary/correct? Both are Dwarf_Addrs
>>>>> which are always uint64_t. And we care about the difference here.
>>>> 
>>>> In my case debug_frame_off is larger than dwbias. If for instance debug_frame_off is 0 and dwbias is -1, the result is -1. As the arithmethics on the 64bit host is unsigned, the result is 0xffffffffffffffff in hex notation and 18446744073709551615 in decimal notation. As stap-symbols.h is used for the target, the values are too large for the 32bit wide unsigned int, which is the data type for the field sec_load_offset. Therefore the compiler complains. The type cast to uint32_t forces the host compiler to use only a 32bit value. Therefore the result is 0xffffffff (4294967295). At least that is what happens on my host. I need the „u“ because even 4294967295 is considered to be too large.
>>>> 
>>>>>> I would like to double check in my environment if we could fall back to the hex notation again.
>>>>> 
>>>>> Isn't it simpler and consistent to just always use decimal in this case?
>>>>> There should at least be a comment why we use a different notation for
>>>>> elf32 vs elf64 targets.
>>>> 
>>>> I would go for a consistent notation. Personally, I prefer the hex notation for the addresses. I hope to be able to check whether the hex notation with casts works tomorrow and get back to you.
>> 
>>> Please find a new version of the patch attached. I changed the patch to use hexadecimal numbers consistently.
>>> 
>>> Kind Regards,
>>> Torsten
>>> <0001-PATCH-v2-Fix-Compilation-fails-for-prelinked-librari.patch>
>> 
>> any comments or thoughts on my proposal?
> 
> Sorry I had forgotten about this issue.
> In your example you have a debug_frame_off with zero and a dwbias of -1.
> That looks somewhat suspicious. Are we sure that isn't a special case?

No, this is not a special case. It’s just a simplified example to illustrate the calculations. ;-)

In my initial mail [1], you can see the original values and calculations.

> The offending line in stap-symbols.h looks as follows:
> .sec_load_offset = 0xffffffffffffebc0 /* 4dec8000 4dec9440 */

The values in the comment are the result of the following instrumentation.

>                  Dwarf_Addr dwbias = 0;
>                  dwfl_module_getdwarf (m, &dwbias);
>                  c->output << ".sec_load_offset = 0x"
>                                    << hex << debug_frame_off - dwbias << dec
>                                    << "/* "  << hex << debug_frame_off << " " << dwbias << dec << "*/"
>                                    << "\n";

This means the actual values are 
debug_frame_off = 0x4dec8000
dwbias          = 0x4dec9440

> The offset of the .text section in the non-prelinked library is 0x15c40. 
> The offset of the .text section in the prelinked library is 0x4decf080 - 0xdeb8000 = 0x17080.
> 
> This means that .sec_load_offset is exactly the difference 0x15c40 - 0x17080 ~ 0xffffffffffffebc0.

You can find the results from a very simple reproduction in [2].

Thanks,
Torsten

[1] https://sourceware.org/ml/systemtap/2015-q4/msg00171.html
[2] https://sourceware.org/ml/systemtap/2015-q4/msg00219.html

Re: Prelinking on ARM with Debug Link

[Mark Wielaard]

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

Hi Torsten,

Sorry this is taking so long. I don't believe I fully understand the
issue. Because I don't immediately know what the right answer is I put
it away for a bit. Then it takes time again to get the full context
(which I believe I still don't fully have).

On Fri, 2016-04-01 at 23:18 +0200, Torsten Polle wrote:
> > Am 01.04.2016 um 15:07 schrieb Mark Wielaard <mjw@redhat.com>:
> > On Wed, 2016-03-30 at 22:05 +0200, Torsten Polle wrote:
> >>> Am 28.02.2016 um 21:51 schrieb Torsten Polle <Torsten.Polle@gmx.de>: 
> >>>> Am 23.02.2016 um 23:16 schrieb Torsten Polle <Torsten.Polle@gmx.de>:
> >>>>> Am 23.02.2016 um 17:46 schrieb Mark Wielaard <mjw@redhat.com>:
> >>>>> 
> >>>>> On Mon, 2016-02-22 at 22:45 +0100, Torsten Polle wrote:
> >>>>>> the principle idea of your patch works. But I had to rewrite it to
> >>>>>> really work in my environment. Could you please have a look at my
> >>>>>> proposal? Would something like that be acceptable?
> >>>>> 
> >>>>> Could you give an example of what didn't work?
> >>>>> You cast both debug_frame_off and dwbias to uint32_t before
> >>>>> substracting. Is that really necessary/correct? Both are Dwarf_Addrs
> >>>>> which are always uint64_t. And we care about the difference here.
> >>>> 
> >>>> In my case debug_frame_off is larger than dwbias. If for instance debug_frame_off is 0 and dwbias is -1, the result is -1. As the arithmethics on the 64bit host is unsigned, the result is 0xffffffffffffffff in hex notation and 18446744073709551615 in decimal notation. As stap-symbols.h is used for the target, the values are too large for the 32bit wide unsigned int, which is the data type for the field sec_load_offset. Therefore the compiler complains. The type cast to uint32_t forces the host compiler to use only a 32bit value. Therefore the result is 0xffffffff (4294967295). At least that is what happens on my host. I need the „u“ because even 4294967295 is considered to be too large.
> >>>> 
> >>>>>> I would like to double check in my environment if we could fall back to the hex notation again.
> >>>>> 
> >>>>> Isn't it simpler and consistent to just always use decimal in this case?
> >>>>> There should at least be a comment why we use a different notation for
> >>>>> elf32 vs elf64 targets.
> >>>> 
> >>>> I would go for a consistent notation. Personally, I prefer the hex notation for the addresses. I hope to be able to check whether the hex notation with casts works tomorrow and get back to you.
> >> 
> >>> Please find a new version of the patch attached. I changed the patch to use hexadecimal numbers consistently.
> >>> 
> >>> Kind Regards,
> >>> Torsten
> >>> <0001-PATCH-v2-Fix-Compilation-fails-for-prelinked-librari.patch>
> >> 
> >> any comments or thoughts on my proposal?
> > 
> > Sorry I had forgotten about this issue.
> > In your example you have a debug_frame_off with zero and a dwbias of -1.
> > That looks somewhat suspicious. Are we sure that isn't a special case?
> 
> No, this is not a special case. It’s just a simplified example to illustrate the calculations. ;-)
> 
> In my initial mail [1], you can see the original values and calculations.
> 
> > The offending line in stap-symbols.h looks as follows:
> > .sec_load_offset = 0xffffffffffffebc0 /* 4dec8000 4dec9440 */
> 
> The values in the comment are the result of the following instrumentation.
> 
> >                  Dwarf_Addr dwbias = 0;
> >                  dwfl_module_getdwarf (m, &dwbias);
> >                  c->output << ".sec_load_offset = 0x"
> >                                    << hex << debug_frame_off - dwbias << dec
> >                                    << "/* "  << hex << debug_frame_off << " " << dwbias << dec << "*/"
> >                                    << "\n";
> 
> This means the actual values are 
> debug_frame_off = 0x4dec8000
> dwbias          = 0x4dec9440
> 
> > The offset of the .text section in the non-prelinked library is 0x15c40. 
> > The offset of the .text section in the prelinked library is 0x4decf080 - 0xdeb8000 = 0x17080.
> > 
> > This means that .sec_load_offset is exactly the difference 0x15c40 - 0x17080 ~ 0xffffffffffffebc0.

OK. So the issue is that we use a hex representation of a negative
number that might not fit when converted to an unsigned value.
The simplest fix seems to be to just use a (signed) decimal
representation, that can be converted to the unsigned value on
assignment. But you prefer to use the hex representation instead?

I don't completely understand what sec_load_offset represents and why it
is an unsigned value. We use it in two places:

runtime/sym.c (_stp_linenumber_lookup):

  // if addr is a kernel address, it will need to be adjusted
  if (!task)
    {
      int i;
      unsigned long offset = 0;
      // have to factor in the load_offset of (specifically) the .text section
      for (i=0; i<m->num_sections; i++)
        if (!strcmp(m->sections[i].name, ".text"))
          {
            offset = (m->sections[i].static_addr - m->sections[i].sec_load_offset);
            break;
          }

      if (addr < offset)
        return 0;
      addr = addr - offset;
    }

runtime/unwind.c (adjustStartLoc):

  if (is_ehframe)
    return startLoc + vm_addr;
  else
    return startLoc + vm_addr - s->sec_load_offset;

The first is clearly only used for the kernel. The second is only used
for .debug_frame addresses. And if you read the rest of the code
(".dynamic" is user space dynamic library (ET_DYN), ".absolute" is user
space executable (ET_EXEC), the kernel has a special name "_stext" and
only kernel modules have section names attached because they are
ET_REL), it looks like sec_load_offset is only used when handling kernel
modules.

This makes sense. Except for kernel modules all other "modules" exist of
just one executable segment/section. But kernel modules (ET_REL files)
can have multiple executable sections with different names and offsets.

So in practice sec_load_offset is only used for kernel modules to
calculate the section static_addr - sec_load_offset.

Given that I think we are solving the wrong problem. Calculating
sec_load_offset for anything except kernel modules doesn't make sense.
So maybe the simplest solution is the attached patch?

It is odd that we only seem to do this for the ".text" section. A kernel
module can have multiple code sections with different names. This isn't
a regression since we never seemed to handle any other section. But if
there are problems unwinding through some kernel modules then this might
explain it.

Cheers,

Mark

[-- Attachment #2: kernel_module_sec_load_offset.patch --]
[-- Type: text/x-patch, Size: 949 bytes --]

diff --git a/translate.cxx b/translate.cxx
index 5daf725..f10c98d 100644
--- a/translate.cxx
+++ b/translate.cxx
@@ -6911,10 +6911,17 @@ dump_unwindsym_cxt (Dwfl_Module *m,
 		    << "_debug_frame_hdr_" << secidx << ",\n";
           c->output << ".debug_hdr_len = " << debug_frame_hdr_len << ", \n";
 
-	  Dwarf_Addr dwbias = 0;
-	  dwfl_module_getdwarf (m, &dwbias);
-	  c->output << ".sec_load_offset = 0x"
-		    << hex << debug_frame_off - dwbias << dec << "\n";
+	  /* Only kernel modules has section names. And the only section
+	     name we are currently interested in (see above) is ".text".  */
+	  if (secname == ".text")
+	    {
+	      Dwarf_Addr dwbias = 0;
+	      dwfl_module_getdwarf (m, &dwbias);
+	      c->output << ".sec_load_offset = 0x"
+			<< hex << debug_frame_off - dwbias << dec << "\n";
+	    }
+	  else
+	    c->output << ".sec_load_offset = 0\n";
 
 	  c->output << "#else\n";
 	  c->output << ".debug_hdr = NULL,\n";

Re: Prelinking on ARM with Debug Link

[Torsten Polle]

Hi Mark,

> Am 05.04.2016 um 15:44 schrieb Mark Wielaard <mjw@redhat.com>:
> 
> [stuff deleted]
> 
> OK. So the issue is that we use a hex representation of a negative
> number that might not fit when converted to an unsigned value.
> The simplest fix seems to be to just use a (signed) decimal
> representation, that can be converted to the unsigned value on
> assignment.

The issue remains if we use decimals. Because even the decimal 0xffffffffffffebc0 = 18446744073709546432 is too large to be represented as 32 bit value. :-(  Therefore my cross compiler on the 64bit host complains.

> But you prefer to use the hex representation instead?

The usage of hex over decimal is just a matter of taste.

> I don't completely understand what sec_load_offset represents and why it
> is an unsigned value. We use it in two places:
> 
> runtime/sym.c (_stp_linenumber_lookup):
> 
>  // if addr is a kernel address, it will need to be adjusted
>  if (!task)
>    {
>      int i;
>      unsigned long offset = 0;
>      // have to factor in the load_offset of (specifically) the .text section
>      for (i=0; i<m->num_sections; i++)
>        if (!strcmp(m->sections[i].name, ".text"))
>          {
>            offset = (m->sections[i].static_addr - m->sections[i].sec_load_offset);
>            break;
>          }
> 
>      if (addr < offset)
>        return 0;
>      addr = addr - offset;
>    }
> 
> runtime/unwind.c (adjustStartLoc):
> 
>  if (is_ehframe)
>    return startLoc + vm_addr;
>  else
>    return startLoc + vm_addr - s->sec_load_offset;

I had twiddled with the else branch in the past. I do not recall all attempts. But I’m sure that I set sec_load_offset even to 0. The result is that the probes are set at the wrong address in libc. To be more concrete they are offset by -5184 compared to the original address. Still I’ll check your patch and let you know the result.

> The first is clearly only used for the kernel. The second is only used
> for .debug_frame addresses. And if you read the rest of the code
> (".dynamic" is user space dynamic library (ET_DYN), ".absolute" is user
> space executable (ET_EXEC), the kernel has a special name "_stext" and
> only kernel modules have section names attached because they are
> ET_REL), it looks like sec_load_offset is only used when handling kernel
> modules.
> 
> This makes sense. Except for kernel modules all other "modules" exist of
> just one executable segment/section. But kernel modules (ET_REL files)
> can have multiple executable sections with different names and offsets.
> 
> So in practice sec_load_offset is only used for kernel modules to
> calculate the section static_addr - sec_load_offset.
> 
> Given that I think we are solving the wrong problem. Calculating
> sec_load_offset for anything except kernel modules doesn't make sense.
> So maybe the simplest solution is the attached patch?
> 
> It is odd that we only seem to do this for the ".text" section. A kernel
> module can have multiple code sections with different names. This isn't
> a regression since we never seemed to handle any other section. But if
> there are problems unwinding through some kernel modules then this might
> explain it.
> 
> Cheers,
> 
> Mark
> diff --git a/translate.cxx b/translate.cxx
> index 5daf725..f10c98d 100644
> --- a/translate.cxx
> +++ b/translate.cxx
> @@ -6911,10 +6911,17 @@ dump_unwindsym_cxt (Dwfl_Module *m,
> 		    << "_debug_frame_hdr_" << secidx << ",\n";
>           c->output << ".debug_hdr_len = " << debug_frame_hdr_len << ", \n";
> 
> -	  Dwarf_Addr dwbias = 0;
> -	  dwfl_module_getdwarf (m, &dwbias);
> -	  c->output << ".sec_load_offset = 0x"
> -		    << hex << debug_frame_off - dwbias << dec << "\n";
> +	  /* Only kernel modules has section names. And the only section
> +	     name we are currently interested in (see above) is ".text".  */
> +	  if (secname == ".text")
> +	    {
> +	      Dwarf_Addr dwbias = 0;
> +	      dwfl_module_getdwarf (m, &dwbias);
> +	      c->output << ".sec_load_offset = 0x"
> +			<< hex << debug_frame_off - dwbias << dec << "\n";
> +	    }
> +	  else
> +	    c->output << ".sec_load_offset = 0\n";
> 
> 	  c->output << "#else\n";
> 	  c->output << ".debug_hdr = NULL,\n“;

Cheers,
Torsten

Re: Prelinking on ARM with Debug Link

[Mark Wielaard]

On Wed, 2016-04-06 at 22:44 +0200, Torsten Polle wrote:
> > Am 05.04.2016 um 15:44 schrieb Mark Wielaard <mjw@redhat.com>:
> > runtime/unwind.c (adjustStartLoc):
> > 
> >  if (is_ehframe)
> >    return startLoc + vm_addr;
> >  else
> >    return startLoc + vm_addr - s->sec_load_offset;
> 
> I had twiddled with the else branch in the past. I do not recall all
> attempts. But I’m sure that I set sec_load_offset even to 0. The
> result is that the probes are set at the wrong address in libc. To be
> more concrete they are offset by -5184 compared to the original
> address. Still I’ll check your patch and let you know the result.

This code is certainly confusing. And arm32 might have different
defaults from all other architectures (which normally have .eh_frames
instead of just .debug_frames, on arm32 unwinding is often done through
EXIDX - exception index tables - instead, but stap doesn't support
those). So it might indeed be that in your case the non-ehframe path is
taken. But I believe that even in that sec_load_offset should be zero.
So it might impact unwinding through user space shared libraries. But it
should not impact setting probe points in shared libraries.

On my own setup (x86_64 native) the patch showed no regressions with
make installcheck. I would be interesting to hear of any test results
you get with my patch.

Thanks,

Mark

Re: Prelinking on ARM with Debug Link

[Torsten Polle]

Hi Mark,

> Am 06.04.2016 um 23:56 schrieb Mark Wielaard <mjw@redhat.com>:
> 
> On Wed, 2016-04-06 at 22:44 +0200, Torsten Polle wrote:
>>> Am 05.04.2016 um 15:44 schrieb Mark Wielaard <mjw@redhat.com>:
>>> runtime/unwind.c (adjustStartLoc):
>>> 
>>> if (is_ehframe)
>>>   return startLoc + vm_addr;
>>> else
>>>   return startLoc + vm_addr - s->sec_load_offset;
>> 
>> I had twiddled with the else branch in the past. I do not recall all
>> attempts. But I’m sure that I set sec_load_offset even to 0. The
>> result is that the probes are set at the wrong address in libc. To be
>> more concrete they are offset by -5184 compared to the original
>> address. Still I’ll check your patch and let you know the result.
> 
> This code is certainly confusing. And arm32 might have different
> defaults from all other architectures (which normally have .eh_frames
> instead of just .debug_frames, on arm32 unwinding is often done through
> EXIDX - exception index tables - instead, but stap doesn't support
> those). So it might indeed be that in your case the non-ehframe path is
> taken. But I believe that even in that sec_load_offset should be zero.

I’ve checked your patch. As a result the backtrace calculations break in my environment.

I’ve therefore instrumented adjustStartLoc() as follows:

  if (is_ehframe) {
    printk(KERN_ERR "eh: s=%lu, v=%lu, l=%lu\n", startLoc, vm_addr, s->sec_load_offset);
    return startLoc + vm_addr;
  }
  else {
    printk(KERN_ERR "no eh: s=%lu, v=%lu, l=%lu\n", startLoc, vm_addr, s->sec_load_offset);
    return startLoc + vm_addr - s->sec_load_offset;
  }

As a result I get the following output:

[ 1215.876537] no eh: s=297684, v=1307279360, l=4294962112
[ 1215.876542] no eh: s=297532, v=1307279360, l=4294962112
[ 1215.876546] no eh: s=297568, v=1307279360, l=4294962112
[ 1215.876551] no eh: s=297612, v=1307279360, l=4294962112
[ 1215.876555] no eh: s=297612, v=1307279360, l=4294962112
[ 1215.876560] no eh: s=297612, v=1307279360, l=4294962112

This means that the non-ehframe path is taken and that sec_load_offset is non-zero.

> So it might impact unwinding through user space shared libraries. But it
> should not impact setting probe points in shared libraries.
> 
> On my own setup (x86_64 native) the patch showed no regressions with
> make installcheck. I would be interesting to hear of any test results
> you get with my patch.
> 
> Thanks,
> 
> Mark

Regards,
Torsten

Re: Prelinking on ARM with Debug Link

[Mark Wielaard]

On Mon, Apr 11, 2016 at 08:47:00PM +0200, Torsten Polle wrote:
> I’ve checked your patch. As a result the backtrace calculations
> break in my environment.

I assume this is an in-kernel backtrace, does it involve kernel modules?
Or is it a user backtrace, executable only? shared libraries?
Could you show a probe script and example backtrace?

Please do include some verbose output. If you can provide the output
of stap -DDEBUG_UNWIND=1 that might be helpful.

> I’ve therefore instrumented adjustStartLoc() as follows:
> 
>   if (is_ehframe) {
>     printk(KERN_ERR "eh: s=%lu, v=%lu, l=%lu\n", startLoc, vm_addr, s->sec_load_offset);
>     return startLoc + vm_addr;
>   }
>   else {
>     printk(KERN_ERR "no eh: s=%lu, v=%lu, l=%lu\n", startLoc, vm_addr, s->sec_load_offset);
>     return startLoc + vm_addr - s->sec_load_offset;
>   }
> 
> As a result I get the following output:
> 
> [ 1215.876537] no eh: s=297684, v=1307279360, l=4294962112
> [ 1215.876542] no eh: s=297532, v=1307279360, l=4294962112
> [ 1215.876546] no eh: s=297568, v=1307279360, l=4294962112
> [ 1215.876551] no eh: s=297612, v=1307279360, l=4294962112
> [ 1215.876555] no eh: s=297612, v=1307279360, l=4294962112
> [ 1215.876560] no eh: s=297612, v=1307279360, l=4294962112
> 
> This means that the non-ehframe path is taken and that sec_load_offset
> is non-zero.

And that calculation wraps around because it is all unsigned.
I admit I don't understand what this calculation represents.

Cheers,

Mark

Re: Prelinking on ARM with Debug Link

[Torsten Polle]

Hi Mark,

> Am 11.04.2016 um 23:01 schrieb Mark Wielaard <mjw@redhat.com>:
> 
> On Mon, Apr 11, 2016 at 08:47:00PM +0200, Torsten Polle wrote:
>> I’ve checked your patch. As a result the backtrace calculations
>> break in my environment.
> 
> I assume this is an in-kernel backtrace, does it involve kernel modules?
> Or is it a user backtrace, executable only? shared libraries?
> Could you show a probe script and example backtrace?

in principle, I’m talking about the example in [1]. In short, I’m talking about getting a proper backtrace in the prelinked library libc-2.18.so. I’m saying „in principle“ because the example does not set a real probe, but only makes SystemTap include the necessary unwinding information for libc-2.18.so.

The real (actually already stripped down) script can be found in [2].

In the script taptrek_run_izA4.stp in line 240, I’m using the following statement
	uaddr = __ustack_raw(depth);
to get backtrace information. Please don’t get distracted by the usage of the function __ustack_raw(). The function print_ubacktrace() would provide a similar result.

> Please do include some verbose output. If you can provide the output
> of stap -DDEBUG_UNWIND=1 that might be helpful.

I’ll try my best and come back to you. I would provide the information with my patch applied, because otherwise the result is simply garbage.

> I’ve therefore instrumented adjustStartLoc() as follows:
>> 
>>  if (is_ehframe) {
>>    printk(KERN_ERR "eh: s=%lu, v=%lu, l=%lu\n", startLoc, vm_addr, s->sec_load_offset);
>>    return startLoc + vm_addr;
>>  }
>>  else {
>>    printk(KERN_ERR "no eh: s=%lu, v=%lu, l=%lu\n", startLoc, vm_addr, s->sec_load_offset);
>>    return startLoc + vm_addr - s->sec_load_offset;
>>  }
>> 
>> As a result I get the following output:
>> 
>> [ 1215.876537] no eh: s=297684, v=1307279360, l=4294962112
>> [ 1215.876542] no eh: s=297532, v=1307279360, l=4294962112
>> [ 1215.876546] no eh: s=297568, v=1307279360, l=4294962112
>> [ 1215.876551] no eh: s=297612, v=1307279360, l=4294962112
>> [ 1215.876555] no eh: s=297612, v=1307279360, l=4294962112
>> [ 1215.876560] no eh: s=297612, v=1307279360, l=4294962112
>> 
>> This means that the non-ehframe path is taken and that sec_load_offset
>> is non-zero.
> 
> And that calculation wraps around because it is all unsigned.
> I admit I don't understand what this calculation represents.

s=297612     =    0x48A8C is a (relative) address in the .text section of libc-2.18.so
v=1307279360 = 0x4DEB8000 is the start address of the loaded libc-2.18.so
l=4294962112 = 0xFFFFEBC0 is the „negative“ sec_load_offset, which accommodates for the offset between the .text section in the prelinked library and the .text section in the non-prelinked file with the debug information.

As a result the location 0x4DF00A8C = 0x4DEB8000 + 0x48A8C in the prelinked file is converted into a location 0x4DEFF64C = 0x4DEB8000 + 0x48A8C  - 0x1440 in the file with debug information, which can be used .

prelinked:                  debug information: 
+----------------------+    +----------------------+
|         ...          |    |         ...          |
+----------------------+    +----------------------+
| .rel.dyn size=0x3c18 |    | .rel.dyn size=0x2810 |
+----------------------+    +----------------------+
|         ...          |    |         ...          |
+----------------------+    +----------------------+
| .text                |    | .text                |
| 0x4DF00A8C           | -> | 0x4DEFF64C           |
+----------------------+    +----------------------+

> Cheers,
> Mark

Regards,
Torsten

[1] https://sourceware.org/ml/systemtap/2015-q4/msg00219.html
[2] https://sourceware.org/ml/systemtap/2015-q4/msg00184.html

Re: Prelinking on ARM with Debug Link

[Mark Wielaard]

Hi Torsten,

On Tue, 2016-04-12 at 22:26 +0200, Torsten Polle wrote:
> > Am 11.04.2016 um 23:01 schrieb Mark Wielaard <mjw@redhat.com>:
> > 
> > On Mon, Apr 11, 2016 at 08:47:00PM +0200, Torsten Polle wrote:
> >> I’ve checked your patch. As a result the backtrace calculations
> >> break in my environment.
> > 
> > I assume this is an in-kernel backtrace, does it involve kernel
> modules?
> > Or is it a user backtrace, executable only? shared libraries?
> > Could you show a probe script and example backtrace?
> 
> in principle, I’m talking about the example in [1]. In short, I’m
> talking about getting a proper backtrace in the prelinked library
> libc-2.18.so. I’m saying „in principle“ because the example does not
> set a real probe, but only makes SystemTap include the necessary
> unwinding information for libc-2.18.so.
> 
> The real (actually already stripped down) script can be found in [2].
> 
> In the script taptrek_run_izA4.stp in line 240, I’m using the
> following statement
> 	uaddr = __ustack_raw(depth);
> to get backtrace information. Please don’t get distracted by the usage
> of the function __ustack_raw(). The function print_ubacktrace() would
> provide a similar result.

I am not sure why the example needs to be so complicated.
The usage of mixed user/kernel space probes/backtraces makes it really
hard to understand what is going on. Can't you show what you get with a
simple probe inside libc.so with a print_ubacktrace?

> > Please do include some verbose output. If you can provide the output
> > of stap -DDEBUG_UNWIND=1 that might be helpful.
> 
> I’ll try my best and come back to you. I would provide the information with my patch applied, because otherwise the result is simply garbage.

Please do include the exact patch you are using.

> > I’ve therefore instrumented adjustStartLoc() as follows:
> >> 
> >>  if (is_ehframe) {
> >>    printk(KERN_ERR "eh: s=%lu, v=%lu, l=%lu\n", startLoc, vm_addr, s->sec_load_offset);
> >>    return startLoc + vm_addr;
> >>  }
> >>  else {
> >>    printk(KERN_ERR "no eh: s=%lu, v=%lu, l=%lu\n", startLoc, vm_addr, s->sec_load_offset);
> >>    return startLoc + vm_addr - s->sec_load_offset;
> >>  }
> >> 
> >> As a result I get the following output:
> >> 
> >> [ 1215.876537] no eh: s=297684, v=1307279360, l=4294962112
> >> [ 1215.876542] no eh: s=297532, v=1307279360, l=4294962112
> >> [ 1215.876546] no eh: s=297568, v=1307279360, l=4294962112
> >> [ 1215.876551] no eh: s=297612, v=1307279360, l=4294962112
> >> [ 1215.876555] no eh: s=297612, v=1307279360, l=4294962112
> >> [ 1215.876560] no eh: s=297612, v=1307279360, l=4294962112
> >> 
> >> This means that the non-ehframe path is taken and that sec_load_offset
> >> is non-zero.
> > 
> > And that calculation wraps around because it is all unsigned.
> > I admit I don't understand what this calculation represents.
> 
> s=297612     =    0x48A8C is a (relative) address in the .text section of libc-2.18.so
> v=1307279360 = 0x4DEB8000 is the start address of the loaded libc-2.18.so
> l=4294962112 = 0xFFFFEBC0 is the „negative“ sec_load_offset, which accommodates for the offset between the .text section in the prelinked library and the .text section in the non-prelinked file with the debug information.
> 
> As a result the location 0x4DF00A8C = 0x4DEB8000 + 0x48A8C in the prelinked file is converted into a location 0x4DEFF64C = 0x4DEB8000 + 0x48A8C  - 0x1440 in the file with debug information, which can be used .
> 
> prelinked:                  debug information: 
> +----------------------+    +----------------------+
> |         ...          |    |         ...          |
> +----------------------+    +----------------------+
> | .rel.dyn size=0x3c18 |    | .rel.dyn size=0x2810 |
> +----------------------+    +----------------------+
> |         ...          |    |         ...          |
> +----------------------+    +----------------------+
> | .text                |    | .text                |
> | 0x4DF00A8C           | -> | 0x4DEFF64C           |
> +----------------------+    +----------------------+

Thanks, that is interesting.
But it is also wrong that we use section offsets in user space modules.
The sections really shouldn't play a role, except for kernel modules.
User space modules are mapped into memory according to their segments
(phdrs). Could you show the segments  plus section to segment mapping of
the libc-2.18.so and libc-2.18.so.debug files used with eu-readelf -Sl

Thanks,

Mark

Aw: Re: Prelinking on ARM with Debug Link

[Torsten Polle]

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

Hi Mark,

> Gesendet: Mittwoch, 13. April 2016 um 11:25 Uhr
> Von: "Mark Wielaard" <mjw@redhat.com>
> An: "Torsten Polle" <Torsten.Polle@gmx.de>
> Cc: systemtap@sourceware.org
> Betreff: Re: Prelinking on ARM with Debug Link
> Hi Torsten,
> 
> On Tue, 2016-04-12 at 22:26 +0200, Torsten Polle wrote:
> > > Am 11.04.2016 um 23:01 schrieb Mark Wielaard <mjw@redhat.com>:
> > >
> > > On Mon, Apr 11, 2016 at 08:47:00PM +0200, Torsten Polle wrote:
> > >> I’ve checked your patch. As a result the backtrace calculations
> > >> break in my environment.
> > >
> > > I assume this is an in-kernel backtrace, does it involve kernel
> > modules?
> > > Or is it a user backtrace, executable only? shared libraries?
> > > Could you show a probe script and example backtrace?
> >
> > in principle, I’m talking about the example in [1]. In short, I’m
> > talking about getting a proper backtrace in the prelinked library
> > libc-2.18.so. I’m saying „in principle“ because the example does not
> > set a real probe, but only makes SystemTap include the necessary
> > unwinding information for libc-2.18.so.
> >
> > The real (actually already stripped down) script can be found in [2].
> >
> > In the script taptrek_run_izA4.stp in line 240, I’m using the
> > following statement
> > uaddr = __ustack_raw(depth);
> > to get backtrace information. Please don’t get distracted by the usage
> > of the function __ustack_raw(). The function print_ubacktrace() would
> > provide a similar result.
> 
> I am not sure why the example needs to be so complicated.
> The usage of mixed user/kernel space probes/backtraces makes it really
> hard to understand what is going on. Can't you show what you get with a
> simple probe inside libc.so with a print_ubacktrace?

This is what I had in mind. ;-) I use the following probe. Please find the result below.

probe process("/lib/libc-2.18.so").function("_int_malloc").call
{
    print_ubacktrace();
}

> > > Please do include some verbose output. If you can provide the output
> > > of stap -DDEBUG_UNWIND=1 that might be helpful.

_stp_stack_unwind_one_user:462: STARTING user unwind
 0x4df2b1b8 : _int_malloc+0x0/0x15f0 [/lib/libc-2.18.so]
_stp_stack_unwind_one_user:478: CONTINUING user unwind to depth 1
unwind:1481: pc=4df2b1b8, 4df2b1b8
unwind:1524: trying debug_frame
_stp_search_unwind_hdr:778: binary search for 4df2b1b8
_stp_search_unwind_hdr:843: fde off=7294
_stp_search_unwind_hdr:853: returning fde=7f4275b8 startLoc=4df2b1b8
unwind_frame:1197: /lib/libc-2.18.so: fde=7f4275b8
unwind_frame:1202: /lib/libc-2.18.so: cie=7f427354
parse_fde_cie:156: map retAddrReg value 14 to reg_info idx 14
unwind_frame:1217: startLoc: 4df2b1b8, endLoc: 4df2c7a8
unwind_frame:1266: cie=7f427354 fde=7f4275b8 startLoc=4df2b1b8 endLoc=4df2c7a8, pc=4df2b1b8
unwind_frame:1286: processCFI for CIE
processCFI:313: targetLoc=0 state->loc=4df2b1b8
processCFI:519: map DW_CFA_def_cfa value 13 to reg_info idx 13
processCFI:521: DW_CFA_def_cfa reg=13
processCFI:530: DW_CFA_def_cfa_offset offs=0
processCFI:649: targetLoc=0 state->loc=4df2b1b8
processCFI:650: result: 1
unwind_frame:1294: processCFI for FDE
processCFI:313: targetLoc=4df2b1b8 state->loc=4df2b1b8
advance_loc:241: state->loc=4df2b1bc
processCFI:617: DW_CFA_advance_loc
processCFI:649: targetLoc=4df2b1b8 state->loc=4df2b1bc
processCFI:650: result: 1
unwind_frame:1313: cfa reg=13, off=0
unwind_frame:1318: cfa=7ed94438 startLoc=7ed94438, endLoc=7ed94438
unwind_frame:1325: cie=7f427354 fde=7f4275b8
unwind_frame:1449: returning 0 (4df2de08)
_stp_stack_unwind_one_user:503: ret=0 PC=4df2de08 SP=7ed94438
 0x4df2de08 : __libc_malloc+0x74/0x204 [/lib/libc-2.18.so]
_stp_stack_unwind_one_user:478: CONTINUING user unwind to depth 2
unwind:1481: pc=4df2de07, 4df2de08
unwind:1524: trying debug_frame
_stp_search_unwind_hdr:778: binary search for 4df2de07
_stp_search_unwind_hdr:843: fde off=73e4
_stp_search_unwind_hdr:853: returning fde=7f427708 startLoc=4df2dd94
unwind_frame:1197: /lib/libc-2.18.so: fde=7f427708
unwind_frame:1202: /lib/libc-2.18.so: cie=7f427354
parse_fde_cie:156: map retAddrReg value 14 to reg_info idx 14
unwind_frame:1217: startLoc: 4df2dd94, endLoc: 4df2df98
unwind_frame:1266: cie=7f427354 fde=7f427708 startLoc=4df2dd94 endLoc=4df2df98, pc=4df2de07
unwind_frame:1286: processCFI for CIE
processCFI:313: targetLoc=0 state->loc=4df2dd94
processCFI:519: map DW_CFA_def_cfa value 13 to reg_info idx 13
processCFI:521: DW_CFA_def_cfa reg=13
processCFI:530: DW_CFA_def_cfa_offset offs=0
processCFI:649: targetLoc=0 state->loc=4df2dd94
processCFI:650: result: 1
unwind_frame:1294: processCFI for FDE
processCFI:313: targetLoc=4df2de07 state->loc=4df2dd94
advance_loc:241: state->loc=4df2dd98
processCFI:617: DW_CFA_advance_loc
processCFI:649: targetLoc=4df2de07 state->loc=4df2dd98
processCFI:650: result: 1
processCFI:530: DW_CFA_def_cfa_offset offs=18
processCFI:649: targetLoc=4df2de07 state->loc=4df2dd98
processCFI:650: result: 1
processCFI:627: map DW_CFA_offset value 3 to reg_info idx 3
set_offset_rule:259: reg=3, where=2, svalue=ffffffe8
processCFI:649: targetLoc=4df2de07 state->loc=4df2dd98
processCFI:650: result: 1
processCFI:627: map DW_CFA_offset value 4 to reg_info idx 4
set_offset_rule:259: reg=4, where=2, svalue=ffffffec
processCFI:649: targetLoc=4df2de07 state->loc=4df2dd98
processCFI:650: result: 1
processCFI:627: map DW_CFA_offset value 5 to reg_info idx 5
set_offset_rule:259: reg=5, where=2, svalue=fffffff0
processCFI:649: targetLoc=4df2de07 state->loc=4df2dd98
processCFI:650: result: 1
processCFI:627: map DW_CFA_offset value 6 to reg_info idx 6
set_offset_rule:259: reg=6, where=2, svalue=fffffff4
processCFI:649: targetLoc=4df2de07 state->loc=4df2dd98
processCFI:650: result: 1
processCFI:627: map DW_CFA_offset value 7 to reg_info idx 7
set_offset_rule:259: reg=7, where=2, svalue=fffffff8
processCFI:649: targetLoc=4df2de07 state->loc=4df2dd98
processCFI:650: result: 1
processCFI:627: map DW_CFA_offset value 14 to reg_info idx 14
set_offset_rule:259: reg=e, where=2, svalue=fffffffc
processCFI:649: targetLoc=4df2de07 state->loc=4df2dd98
processCFI:650: result: 1
processCFI:322: DW_CFA_nop
processCFI:649: targetLoc=4df2de07 state->loc=4df2dd98
processCFI:650: result: 1
unwind_frame:1313: cfa reg=13, off=18
unwind_frame:1318: cfa=7ed94450 startLoc=7ed94438, endLoc=7ed94450
unwind_frame:1325: cie=7f427354 fde=7f427708
unwind_frame:1439: set register 3 to 7ed94488
unwind_frame:1439: set register 4 to 47
unwind_frame:1439: set register 5 to 7ed94474
unwind_frame:1439: set register 6 to 2f580
unwind_frame:1439: set register 7 to 8
unwind_frame:1439: set register 14 to 23a30
unwind_frame:1449: returning 0 (23a30)
_stp_stack_unwind_one_user:503: ret=0 PC=23a30 SP=7ed94450
 0x23a30 [/lib/systemd/systemd-udevd+0x1ba30/0x35000]
_stp_stack_unwind_one_user:478: CONTINUING user unwind to depth 3
unwind:1481: pc=23a2f, 23a30
unwind:1520: No module found for pc=23a2f
_stp_stack_unwind_one_user:503: ret=-22 PC=23a30 SP=7ed94450


> > I’ll try my best and come back to you. I would provide the
> > information with my patch applied, because otherwise the result is
> > simply garbage.
> 
> Please do include the exact patch you are using.

Please find the patch attached.

> Thanks, that is interesting.
> But it is also wrong that we use section offsets in user space modules.
> The sections really shouldn't play a role, except for kernel modules.
> User space modules are mapped into memory according to their segments
> (phdrs). Could you show the segments plus section to segment mapping of
> the libc-2.18.so and libc-2.18.so.debug files used with eu-readelf -Sl

Please check [1] for the requested output.

This means sec_load_offset should be 0 as you proposed in your
patch. But then the question is where you want to adjust for the
necessary difference between offsets.

> Thanks,
> 
> Mark

Thanks,
Torsten

[1] https://sourceware.org/ml/systemtap/2015-q4/msg00219.html

[-- Attachment #2: 0001-PATCH-v2-Fix-Compilation-fails-for-prelinked-librari.patch --]
[-- Type: application/octet-stream, Size: 3021 bytes --]

From ce284b4398627305714a10c5f436a4c0b2ae39e8 Mon Sep 17 00:00:00 2001
Message-Id: <ce284b4398627305714a10c5f436a4c0b2ae39e8.1460557495.git.tpolle@de.adit-jv.com>
From: Torsten Polle <Torsten.Polle@gmx.de>
Date: Sun, 28 Feb 2016 21:45:33 +0100
Subject: [PATCH] [PATCH v2] Fix: Compilation fails for prelinked libraries.

The offset to the section ".text" in a prelinked library might increase due to
changed relocations that need more space. If the prelinked library contains a
debug link and the linked file is not prelinked, the offset to the ".text"
section is different. If the difference between the offset of the ".text"
section in the prelinked library and non-prelinked library (with e.g. debug
information) becomes negative, the representation of this negative number has
to fit into an uint32_t. If the width of the host is larger than the
width of the target, the (cross-) compilation for the target fails.

Changes since v1:
* Use hex values for the 32bit case.

Signed-off-by: Torsten Polle <tpolle@de.adit-jv.com>
---
 translate.cxx |   34 ++++++++++++++++++++++++++++++----
 1 file changed, 30 insertions(+), 4 deletions(-)

diff --git a/translate.cxx b/translate.cxx
index 5daf725..fcd2d8e 100644
--- a/translate.cxx
+++ b/translate.cxx
@@ -6912,9 +6912,22 @@ dump_unwindsym_cxt (Dwfl_Module *m,
           c->output << ".debug_hdr_len = " << debug_frame_hdr_len << ", \n";
 
 	  Dwarf_Addr dwbias = 0;
+	  Dwarf_Addr elf_bias;
+	  GElf_Ehdr *ehdr, ehdr_mem;
+	  Elf *elf;
+	  elf = dwfl_module_getelf(m, &elf_bias);
+	  ehdr = gelf_getehdr(elf, &ehdr_mem);
 	  dwfl_module_getdwarf (m, &dwbias);
-	  c->output << ".sec_load_offset = 0x"
-		    << hex << debug_frame_off - dwbias << dec << "\n";
+	  if (ehdr->e_ident[EI_CLASS] == ELFCLASS32)
+	    {
+	      c->output << ".sec_load_offset = 0x"
+			<< hex << (uint32_t)(debug_frame_off - dwbias) << dec << "\n";
+	    }
+	  else
+	    {
+	      c->output << ".sec_load_offset = 0x"
+			<< hex << debug_frame_off - dwbias << dec << "\n";
+	    }
 
 	  c->output << "#else\n";
 	  c->output << ".debug_hdr = NULL,\n";
@@ -6932,9 +6945,22 @@ dump_unwindsym_cxt (Dwfl_Module *m,
             {
               c->output << "#if defined(STP_NEED_LINE_DATA)\n";
               Dwarf_Addr dwbias = 0;
+	      Dwarf_Addr elf_bias;
+	      GElf_Ehdr *ehdr, ehdr_mem;
+	      Elf *elf;
+	      elf = dwfl_module_getelf(m, &elf_bias);
+	      ehdr = gelf_getehdr(elf, &ehdr_mem);
               dwfl_module_getdwarf (m, &dwbias);
-              c->output << ".sec_load_offset = 0x"
-                        << hex << debug_frame_off - dwbias << dec << "\n";
+	      if (ehdr->e_ident[EI_CLASS] == ELFCLASS32)
+		{
+		  c->output << ".sec_load_offset = 0x"
+			    << hex << (uint32_t)(debug_frame_off - dwbias) << dec << "\n";
+		}
+	      else
+		{
+		  c->output << ".sec_load_offset = 0x"
+			    << hex << debug_frame_off - dwbias << dec << "\n";
+		}
               c->output << "#else\n";
             }
 	  c->output << ".sec_load_offset = 0\n";
-- 
1.7.9.5