This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: Aw: Re: Prelinking on ARM with Debug Link
- From: Mark Wielaard <mjw at redhat dot com>
- To: Torsten Polle <Torsten dot Polle at gmx dot de>
- Cc: systemtap at sourceware dot org
- Date: Tue, 16 Feb 2016 11:08:32 +0100
- Subject: Re: Aw: Re: Prelinking on ARM with Debug Link
- Authentication-results: sourceware.org; auth=none
- References: <4BCA4243-B16B-436F-9D53-41C551492A51 at gmx dot de> <6E47DD0A-0515-45C6-86A1-4669A8182663 at gmx dot de> <1455121041 dot 7606 dot 104 dot camel at redhat dot com> <3855EE25-54F2-47FB-88A8-FF1EC3963C06 at gmx dot de> , <1455136517 dot 7606 dot 107 dot camel at redhat dot com> <trinity-fb9190d9-ee29-4674-8066-0251f630d69b-1455187752264 at 3capp-gmx-bs27>
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