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