> 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