Re: Prelinking on ARM with Debug Link

[Torsten Polle <Torsten dot Polle at gmx dot de>]

Hi Mark,

Mark Wielaard writes:
 > Hi Torsten,

 > On Wed, 2015-11-25 at 21:52 +0100, Torsten Polle wrote:
 >> Here I have a problem to compile my probes when I want to include unwind information.
 >> 
 >> The error message is as follow:
 >> 
 >> In file included from /tmp/stap/taptrek_src.c:6010:0:
 >> /tmp/stap/stap-symbol.h:95831:1: error: large integer implicitly truncated to unsigned type [-Werror=overflow]
 >> },
 >> ^
 >> 
 >> The offending line in stap-symbols.h looks as follows:
 >> .sec_load_offset = 0xffffffffffffebc0 /* 4dec8000 4dec9440*/
 >> 
 >> The line includes debug output, because I checked the code in
 >> translate.cxx that generates this output and wanted to understand
 >> what is going wrong.
 >> 
 >> 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";
 >> 
 >> As I use a 64bit host, the hex value is given as 64bit long hex
 >> value. Additional the value is very large, because the value is
 >> actually the difference between debug_frame_off=0x4dec8000 and
 >> dwbias=0x4dec9440. As dwbias is larger than debug_frame_off, the
 >> value becomes negative. But the field .sec_load_offset as unsigned
 >> long and therefore does not take negative values.

 > Yeah, this goes wrong since you are cross compiling for 32bit, so
 > unsigned long is "suddenly" smaller than expected.

 > I don't immediately know what the correct solution is. the
 > sec_load_offset is defined for _stp_section with the following comment:

 >         /* Synthesized index for .debug_frame table, keep section
 >            offset to adjust addresses relative to load address. */
 >         void *debug_hdr;
 >         uint32_t debug_hdr_len;
 >         unsigned long sec_load_offset;

 > I added this a couple of years back:

 > commit 4d83bd9b6f5ccc4abd212ca5d6a6477cb52f78cc
 > Author: Mark Wielaard <mjw@redhat.com>
 > Date:   Mon Jul 5 21:14:42 2010 +0200

 >   Put generated debug_hdr in _stp_section, add sec_load_offset for adjustment.
    
 >   Make sure to adjust .debug_frame addresses to section load address.
 >   Which means keeping track of the (synthetic) .debug_frame_hdr index
 >   per section. For now keep track of "magic sections". Will need to
 >   be extended to track all loadable code sections as we do for symbol
 >   tables. See http://sourceware.org/ml/systemtap/2010-q3/msg00012.html

 > So the problem we are facing is that kernel modules aren't ET_DYN, but
 > ET_REL files and the separate sections themselves are relocatable. So we
 > want to keep the load offset per (code) section.

 > We need that offset since we are creating a binary search table for
 > the .debug_frame (.eh_frame always comes with .eh_frame_hdr,
 > but .debug_frame would normally require a linear search which we want to
 > avoid). See adjustStartLoc in unwind.c.

 > Later this got extended to also be used by _stp_linenumber_lookup for
 > kernel modules, apparently for the same reason.

 > commit 598a50ae1cbc0f84914a4eee56a287273bb420b7
 > Author: Abegail Jakop <ajakop@redhat.com>
 > Date:   Mon Dec 22 15:04:34 2014 -0500

 >   PR12276: fix addr adjustment for symfileline()
    
 >   runtime/sym*: adjust the given address to account for the load offset
 >   runtime/transport/symbols.c: include the body of _stp_module_update_self()
 >   if STP_NEED_LINE_DATA so that the sec_load_offset can be updated
 >   tapset/linux/context-symbols.stp: remove the pragma myproc-unpriveleged
 >   since it's spelled wrong, and it's not needed anyways
 >   translate.cxx: add funtion find_debug_frame_offset() to set the
 >   sec_load_offset for the ".text" section

 > I assume it is the first usage (under STP_NEED_UNWIND_DATA) but the
 > other code looks similar (under STP_NEED_LINE_DATA).

 > It looks like the debug_frame_off is setup differently for the two
 > cases. So it might be good to investigate which one is used in the case
 > above to help our investigation.

I had some problems with my mailer. I apology if you got this mail twice.

Your assumption is correct. It is the first usage (under STP_NEED_UNWIND_DATA).

 > Thanks,
 > Mark

Kind Regards,
Torsten