|
From: Josef W. <Jos...@gm...> - 2005-11-15 09:39:56
|
Hi,
I have a better working callgrind for PPC now ...
Two issues:
1) There is a "strange function" with a single instruction "blrl".
It is called quite often at the start of any code in /lib/ld.so,
address 0x04027528; ld.so is mapped starting from 0x04000000.
According to objdump, 27528 is still part of ld.so:
objdump -d /lib/ld-2.3.5.so | less
Disassembly of section .got:
00027000 <.got>:
...
27528: 4e 80 00 21 blrl
2752c: 00 02 6f 50 .long 0x26f50
...
So this is code in the GOT table. Thus, the code seems to put the
GOT of a DSO into lr, which then often is put into an general
purpose register (e.g. with mflr r30).
According to callgrind debug output, address 0x04027528 is not attributed
to any segment by valgrind (using VG_(find_seginfo)()).
Looking at proc/XXX/maps, I get:
04000000-04017000 r-xp 00000000 03:03 557124 /lib/ld-2.3.5.so
04017000-0401c000 rw-p 04017000 00:00 0
04026000-04027000 r--p 00016000 03:03 557124 /lib/ld-2.3.5.so
04027000-04028000 rwxp 00017000 03:03 557124 /lib/ld-2.3.5.so
Does anybody have an idea what can cause this?
I use the segment info to decide if a boring jump should be changed
to a call (ie. when crossing segment boundaries; this is for x86/x86_64
from PLT section to another DSO).
Josef
|
|
From: Tom H. <to...@co...> - 2005-11-15 11:26:43
|
In message <200...@gm...>
Josef Weidendorfer <Jos...@gm...> wrote:
> According to callgrind debug output, address 0x04027528 is not attributed
> to any segment by valgrind (using VG_(find_seginfo)()).
> Looking at proc/XXX/maps, I get:
>
> 04000000-04017000 r-xp 00000000 03:03 557124 /lib/ld-2.3.5.so
> 04017000-0401c000 rw-p 04017000 00:00 0
> 04026000-04027000 r--p 00016000 03:03 557124 /lib/ld-2.3.5.so
> 04027000-04028000 rwxp 00017000 03:03 557124 /lib/ld-2.3.5.so
>
> Does anybody have an idea what can cause this?
Sounds like the segment list and the maps file are out of sync for
some reason, which is bad. What does --sanity-level=4 say? Does it
report a sync check failure?
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Tom H. <to...@co...> - 2005-11-15 11:29:16
|
In message <172...@ca...>
Paul Mackerras <pa...@sa...> wrote:
> Josef Weidendorfer writes:
>
>> According to callgrind debug output, address 0x04027528 is not attributed
>> to any segment by valgrind (using VG_(find_seginfo)()).
>> Looking at proc/XXX/maps, I get:
>>
>> 04000000-04017000 r-xp 00000000 03:03 557124 /lib/ld-2.3.5.so
>> 04017000-0401c000 rw-p 04017000 00:00 0
>> 04026000-04027000 r--p 00016000 03:03 557124 /lib/ld-2.3.5.so
>> 04027000-04028000 rwxp 00017000 03:03 557124 /lib/ld-2.3.5.so
>>
>> Does anybody have an idea what can cause this?
>
> What particular aspect of that are you asking about? It looks OK to
> me; the r--p bit is the relro section (relocation read-only), which is
> read/write while relocations are being done and then gets changed to
> read-only. The rwxp is the rest of the data section.
Why does the data section have execute permission? It wouldn't
normally have that on x86/amd64 systems.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Tom H. <to...@co...> - 2005-11-15 11:30:47
|
In message <yek...@de...>
Tom Hughes <to...@co...> wrote:
> In message <200...@gm...>
> Josef Weidendorfer <Jos...@gm...> wrote:
>
>> According to callgrind debug output, address 0x04027528 is not attributed
>> to any segment by valgrind (using VG_(find_seginfo)()).
>> Looking at proc/XXX/maps, I get:
>>
>> 04000000-04017000 r-xp 00000000 03:03 557124 /lib/ld-2.3.5.so
>> 04017000-0401c000 rw-p 04017000 00:00 0
>> 04026000-04027000 r--p 00016000 03:03 557124 /lib/ld-2.3.5.so
>> 04027000-04028000 rwxp 00017000 03:03 557124 /lib/ld-2.3.5.so
>>
>> Does anybody have an idea what can cause this?
>
> Sounds like the segment list and the maps file are out of sync for
> some reason, which is bad. What does --sanity-level=4 say? Does it
> report a sync check failure?
Oh hang on, you're talking about SegInfo not NSegment... Not finding
a SegInfo just means there is no debug information associated with the
address which is normal if that is the data segment.
You might be better off querying the address space manager which will
have a segment for all mapped memory.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Julian S. <js...@ac...> - 2005-11-15 11:37:42
|
> > Sounds like the segment list and the maps file are out of sync for > > some reason, which is bad. What does --sanity-level=4 say? Does it > > report a sync check failure? > > Oh hang on, you're talking about SegInfo not NSegment... Not finding > a SegInfo just means there is no debug information associated with the > address which is normal if that is the data segment. Ah, good point. > You might be better off querying the address space manager which will > have a segment for all mapped memory. Yes. VG_(am_find_nsegment) is what you need to call -- this should match (almost) exactly the current state of /proc/self/maps. J |
|
From: Paul M. <pa...@sa...> - 2005-11-15 11:40:28
|
Tom Hughes writes: > Why does the data section have execute permission? It wouldn't > normally have that on x86/amd64 systems. Two reasons: (1) you have to be able to execute the blrl at the base of the GOT, and (2) procedure calls between objects jump into the PLT, which contains instructions for either calling the dynamic linker or jumping to the procedure. Paul. |
|
From: Tom H. <to...@co...> - 2005-11-15 11:44:17
|
In message <172...@ca...>
Paul Mackerras <pa...@sa...> wrote:
> Tom Hughes writes:
>
>> Why does the data section have execute permission? It wouldn't
>> normally have that on x86/amd64 systems.
>
> Two reasons: (1) you have to be able to execute the blrl at the base
> of the GOT, and (2) procedure calls between objects jump into the PLT,
> which contains instructions for either calling the dynamic linker or
> jumping to the procedure.
The PLT shouldn't be an issue as that is normally adjacent to the
text section so it will be part of the first mapping. Or is that
different on ppc as well?
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Josef W. <Jos...@gm...> - 2005-11-15 16:03:58
|
Thanks everybody. On Tuesday 15 November 2005 12:38, Julian Seward wrote: > Yes. VG_(am_find_nsegment) is what you need to call -- this should match > (almost) exactly the current state of /proc/self/maps. Fine. So how do I detect that this is in the GOT of some DSO? VG_(find_seginfo) will give no SegInfo. So I use VG_(am_find_nsegment), and see that the returned segment has the DSO associated (SkFileC). I just saw that only ld.so has this problem (not returning a SegInfo). Quite strange. For all other DSOs, I get e.g. the following call tree: > call_init(0x2020202E, 0x2020202E, ...) [ld-2.3.5.so / 0xB5D0] .> 0x04027528(0x2020202E, 0x2020202E, ...) [??? / 0x4027528] .> 0x00004500(0x2020202E, 0x2020202E, ...) [libpthread-2.3.5.so / 0x4500] . > 0x00004530(0x2020202E, 0x2020202E, ...) [libpthread-2.3.5.so / 0x4530] . > 0x00021160 [GOT](0x2020202E, 0x2020202E, ...) [libpthread-2.3.5.so / 0x21160] And at 0x00021160 in libpthread-2.3.5.so, I have the blrl again. Another question is why VG_(get_fnname) can not see the function name for libpthread-2.3.5.so:0x4500 and 0x4530. objdump and nm get them both fine: 4500 is _init, 4530 is call_initialize_minimal... Josef |
|
From: Tom H. <to...@co...> - 2005-11-15 16:49:10
|
In message <200...@gm...>
Josef Weidendorfer <Jos...@gm...> wrote:
> Thanks everybody.
>
> On Tuesday 15 November 2005 12:38, Julian Seward wrote:
>> Yes. VG_(am_find_nsegment) is what you need to call -- this should match
>> (almost) exactly the current state of /proc/self/maps.
>
> Fine.
> So how do I detect that this is in the GOT of some DSO?
Dunno ;-)
> VG_(find_seginfo) will give no SegInfo.
> So I use VG_(am_find_nsegment), and see that the returned
> segment has the DSO associated (SkFileC).
>
> I just saw that only ld.so has this problem (not returning a SegInfo).
Only the text segment will normally have a SegInfo - the full rules
can be found in VG_(di_notify_mmap) in m_debuginfo/symtab.c but it
looks like:
ok = (seg->kind == SkFileC || (seg->kind == SkFileV && allow_SkFileV))
&& seg->offset == 0
&& seg->fnIdx != -1
&& seg->hasR
&& seg->hasX
&& !seg->hasW
&& is_elf_object_file( (const void*)seg->start );
So it has to be a file mapping at offset zero in the file that has read
and execute permission but not write permission. It also needs to look
like an ELF file.
So the data segment of ld.so is ruled out both because it is not at
offset zero and because it has write permission.
> Quite strange.
> For all other DSOs, I get e.g. the following call tree:
>
> > call_init(0x2020202E, 0x2020202E, ...) [ld-2.3.5.so / 0xB5D0]
> .> 0x04027528(0x2020202E, 0x2020202E, ...) [??? / 0x4027528]
> .> 0x00004500(0x2020202E, 0x2020202E, ...) [libpthread-2.3.5.so / 0x4500]
> . > 0x00004530(0x2020202E, 0x2020202E, ...) [libpthread-2.3.5.so / 0x4530]
> . > 0x00021160 [GOT](0x2020202E, 0x2020202E, ...) [libpthread-2.3.5.so / 0x21160]
>
> And at 0x00021160 in libpthread-2.3.5.so, I have the blrl again.
Where does that [GOT] marker come from? What is the logic that
triggers it?
> Another question is why VG_(get_fnname) can not see the function name
> for libpthread-2.3.5.so:0x4500 and 0x4530. objdump and nm get them both
> fine: 4500 is _init, 4530 is call_initialize_minimal...
Which objdump/nm option? static or dynamic symbol table? or both?
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Josef W. <Jos...@gm...> - 2005-11-15 17:33:47
|
On Tuesday 15 November 2005 17:49, Tom Hughes wrote:
> > > call_init(0x2020202E, 0x2020202E, ...) [ld-2.3.5.so / 0xB5D0]
> > .> 0x04027528(0x2020202E, 0x2020202E, ...) [??? / 0x4027528]
> > .> 0x00004500(0x2020202E, 0x2020202E, ...) [libpthread-2.3.5.so / 0x4500]
> > . > 0x00004530(0x2020202E, 0x2020202E, ...) [libpthread-2.3.5.so / 0x4530]
> > . > 0x00021160 [GOT](0x2020202E, 0x2020202E, ...) [libpthread-2.3.5.so / 0x21160]
> >
> > And at 0x00021160 in libpthread-2.3.5.so, I have the blrl again.
>
> Where does that [GOT] marker come from? What is the logic that
> triggers it?
It is from src/fn.c to assign names to addresses where no debug
info is found (bb is a structure for the basic block)
...
if (0 == VG_(strcmp)(fnname, "???")) {
int p;
/* Use address as found in library */
if (sizeof(Addr) == 4)
p = VG_(sprintf)(fnname, "%08p", bb->offset);
else
// 64bit address
p = VG_(sprintf)(fnname, "%016p", bb->offset);
VG_(sprintf)(fnname+p, "%s",
(bb->sect_kind == Vg_SectData) ? " [Data]" :
(bb->sect_kind == Vg_SectBSS) ? " [BSS]" :
(bb->sect_kind == Vg_SectGOT) ? " [GOT]" :
(bb->sect_kind == Vg_SectPLT) ? " [PLT]" : "");
}
and bb->sect_kind is set by VG_(seginfo_sect_kind)(addr)
> Which objdump/nm option? static or dynamic symbol table? or both?
% nm /lib/tls/libpthread-2.3.5.so | grep 4500
00004500 t _init
Ie. static. It is not found in the dynamic one.
Josef
|
|
From: Josef W. <Jos...@gm...> - 2005-11-15 16:52:59
|
On Tuesday 15 November 2005 17:03, Josef Weidendorfer wrote: > So I use VG_(am_find_nsegment), and see that the returned > segment has the DSO associated (SkFileC). Uhm.. how do I get the segname of a NSegment from a tool? I only have fnIdx... I suppose this needs a function Char* VG_(am_get_segname)(Int fnIdx) Josef |
|
From: Tom H. <to...@co...> - 2005-11-15 17:00:55
|
In message <200...@gm...>
Josef Weidendorfer <Jos...@gm...> wrote:
> On Tuesday 15 November 2005 17:03, Josef Weidendorfer wrote:
>> So I use VG_(am_find_nsegment), and see that the returned
>> segment has the DSO associated (SkFileC).
>
> Uhm.. how do I get the segname of a NSegment from a tool?
> I only have fnIdx...
>
> I suppose this needs a function
> Char* VG_(am_get_segname)(Int fnIdx)
A bit like VG_(am_get_filename) you mean ;-)
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Jeroen N. W. <jn...@xs...> - 2005-11-15 17:08:43
|
> In message <200...@gm...> > Josef Weidendorfer <Jos...@gm...> wrote: > >> On Tuesday 15 November 2005 17:03, Josef Weidendorfer wrote: >>> So I use VG_(am_find_nsegment), and see that the returned >>> segment has the DSO associated (SkFileC). >> >> Uhm.. how do I get the segname of a NSegment from a tool? >> I only have fnIdx... >> >> I suppose this needs a function >> Char* VG_(am_get_segname)(Int fnIdx) > > A bit like VG_(am_get_filename) you mean ;-) Which is in coregrind/pub_core_aspacemgr.h, not in include/pub_tool_aspacemgr.h ... I needed to move it, for blanket. I don't see why this interface cannot be public. Jeroen. |
|
From: Tom H. <to...@co...> - 2005-11-15 17:59:34
|
In message <200...@gm...>
Josef Weidendorfer <Jos...@gm...> wrote:
> and bb->sect_kind is set by VG_(seginfo_sect_kind)(addr)
I don't see how bb->sect_kind is supposed to work - it will work if
you call it on the right SegInfo, but if you look up a GOT address
you're not likely to find the SegInfo...
I wonder if the ifdefed out code at the end of read_lib_symbols
has something to do with this - that looks like it is trying to
find other mappings and extend the SegInfo to cover them.
> > Which objdump/nm option? static or dynamic symbol table? or both?
>
> % nm /lib/tls/libpthread-2.3.5.so | grep 4500
> 00004500 t _init
>
> Ie. static. It is not found in the dynamic one.
Hmm. Well we definitely read both so that should be find.
I wonder if the address appears to be outside the mapping that
valgrind has associated the SegInfo with.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Tom H. <to...@co...> - 2005-11-15 19:19:41
Attachments:
valgrind-symtab.patch
|
In message <34b...@lo...>
Tom Hughes <to...@co...> wrote:
> In message <200...@gm...>
> Josef Weidendorfer <Jos...@gm...> wrote:
>
> > and bb->sect_kind is set by VG_(seginfo_sect_kind)(addr)
>
> I don't see how bb->sect_kind is supposed to work - it will work if
> you call it on the right SegInfo, but if you look up a GOT address
> you're not likely to find the SegInfo...
>
> I wonder if the ifdefed out code at the end of read_lib_symbols
> has something to do with this - that looks like it is trying to
> find other mappings and extend the SegInfo to cover them.
Does this patch help? It reinstates part of the ifdefed out code.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Josef W. <Jos...@gm...> - 2005-11-15 23:27:09
|
> Does this patch help? It reinstates part of the ifdefed out code. Yes. 21160 is in GOT of libpthread-2.3.5.so again: .> 0x00004500(0x2020202E, 0x2020202E, ...) [libpthread-2.3.5.so / 0x4500] . > 0x00004530(0x2020202E, 0x2020202E, ...) [libpthread-2.3.5.so / 0x4530] . > 0x00021160 [GOT](0x2020202E, 0x2020202E, ...) [libpthread-2.3.5.so / 0x21160] BTW: You can get this call tree with callgrind --ct-verbose=1 ... Perhaps these missing symbols are not really a fault of Valgrind: % objdump -t /lib/tls/libpthread-2.3.5.so /lib/tls/libpthread-2.3.5.so: file format elf32-powerpc SYMBOL TABLE: 00004530 l F .text 00000000 call_initialize_minimal ... 00004500 l F .init 00000000 _init Both have size 0, and AFAIK, the symbol reader skips these. I have no idea why these have size 0. Perhaps handcrafted assembler. Perhaps we could artificially change the size to 1 for functions of size 0? I have no idea how much this increases the number of symbols, though. Josef |
|
From: Tom H. <to...@co...> - 2005-11-16 00:12:59
|
In message <200...@gm...>
Josef Weidendorfer <Jos...@gm...> wrote:
> > Does this patch help? It reinstates part of the ifdefed out code.
>
> Yes. 21160 is in GOT of libpthread-2.3.5.so again:
>
> .> 0x00004500(0x2020202E, 0x2020202E, ...) [libpthread-2.3.5.so / 0x4500]
> . > 0x00004530(0x2020202E, 0x2020202E, ...) [libpthread-2.3.5.so / 0x4530]
> . > 0x00021160 [GOT](0x2020202E, 0x2020202E, ...) [libpthread-2.3.5.so / 0x21160]
I've committed that patch now then.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Julian S. <js...@ac...> - 2005-11-15 20:26:23
|
> >> Uhm.. how do I get the segname of a NSegment from a tool? > >> I only have fnIdx... > >> > >> I suppose this needs a function > >> Char* VG_(am_get_segname)(Int fnIdx) > > > > A bit like VG_(am_get_filename) you mean ;-) > > Which is in coregrind/pub_core_aspacemgr.h, not in > include/pub_tool_aspacemgr.h ... I needed to move it, for blanket. I don't > see why this interface cannot be public. These things can certainly be made public. You shouldn't view the set of core functions available to tools as fixed and unchangeable. It's just that until now we knew of no need to make it public, and in general there is a desire to minimise the amount of core functionality that tools can see, for the usual software-engineering reasons. So what you want is for VG_(am_get_filename) to moved to the tool iface file, and also VG_(am_get_segname) to be created, yes? J |
|
From: Jeroen N. W. <jn...@xs...> - 2005-11-15 20:34:29
|
> >> >> Uhm.. how do I get the segname of a NSegment from a tool? >> >> I only have fnIdx... >> >> >> >> I suppose this needs a function >> >> Char* VG_(am_get_segname)(Int fnIdx) >> > >> > A bit like VG_(am_get_filename) you mean ;-) >> >> Which is in coregrind/pub_core_aspacemgr.h, not in >> include/pub_tool_aspacemgr.h ... I needed to move it, for blanket. I >> don't >> see why this interface cannot be public. > > These things can certainly be made public. You shouldn't view the > set of core functions available to tools as fixed and unchangeable. > It's just that until now we knew of no need to make it public, and > in general there is a desire to minimise the amount of core functionality > that tools can see, for the usual software-engineering reasons. > > So what you want is for VG_(am_get_filename) to moved to the tool > iface file, and also VG_(am_get_segname) to be created, yes? I would like VG_(am_get_filename) to moved to the tool iface file, yes. I don't understand about VG_(am_get_segname). The name of the segment is the name of the file to which the segment is mapped, or from which the segment was loaded; right? Jeroen. |
|
From: Josef W. <Jos...@gm...> - 2005-11-15 23:27:08
|
On Tuesday 15 November 2005 21:34, Jeroen N. Witmond wrote: > I would like VG_(am_get_filename) to moved to the tool iface file, yes. I > don't understand about VG_(am_get_segname). The name of the segment is the > name of the file to which the segment is mapped, or from which the segment > was loaded; right? There is no VG_(am_get_segname) and there will be no need for it ;-) I didn't find VG_(am_get_filename) in pub_tool_aspacemgr.h, so I proposed a quite bad name for it (because the variable is called segname[]). I am not sure if I need it, but if tools already have access to ASpaceMgr, it is desirable to get the name of a mapped file, too. Julian: yes, please put VG_(am_get_filename) into pub_tool_aspacemgr.h. A wish regarding the tool interface for the future: it would be good to be able to get a string representation of a guest assembler instruction. This way, assembler annotation could be done by visualization tools without dependency on "objdump" and the executed binary. Two advantages: Profile data with assembler code of executed instructions is * more self-contained, i.e. I could copy profile data from the PPC machine to look at PPC assembler annotation on my (offline) laptop * the handling of comparing profile data before and after a code change is easier; at the moment, I need to have access to the old binaries; and if they get deleted (by make or whatever), assembler annotation is not possible any longer Josef |
|
From: Tom H. <to...@co...> - 2005-11-16 00:13:39
|
In message <200...@gm...>
Josef Weidendorfer <Jos...@gm...> wrote:
> There is no VG_(am_get_segname) and there will be no need for it ;-)
>
> I didn't find VG_(am_get_filename) in pub_tool_aspacemgr.h, so I proposed
> a quite bad name for it (because the variable is called segname[]).
>
> I am not sure if I need it, but if tools already have access to ASpaceMgr,
> it is desirable to get the name of a mapped file, too.
> Julian: yes, please put VG_(am_get_filename) into pub_tool_aspacemgr.h.
I've moved it into pub_tool_aspacemgr.h for you.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Nicholas N. <nj...@cs...> - 2005-11-16 00:21:17
|
On Tue, 15 Nov 2005, Josef Weidendorfer wrote: > A wish regarding the tool interface for the future: it would be good to > be able to get a string representation of a guest assembler instruction. I think this is a good idea too; it was a suggestion I had back before Vex was written but it got lost along the way. The string could be attached to each IMark. The DIP and DIS macros used in */toIR.c could be used as the basis of this. One neat effect is that it would allow tools to do platform-specific things if they really wanted to. Nick |
|
From: Paul M. <pa...@sa...> - 2005-11-15 11:21:27
|
Josef Weidendorfer writes: > 1) There is a "strange function" with a single instruction "blrl". > It is called quite often at the start of any code in /lib/ld.so, > address 0x04027528; ld.so is mapped starting from 0x04000000. In the current PPC32 ELF ABI, there is a blrl instruction in the word before the start of the GOT (global offset table). Shared libraries use a bl GOT-4 to get the address of the GOT into LR in position-independent code. I wouldn't consider the bl and blrl to denote a function call. > According to callgrind debug output, address 0x04027528 is not attributed > to any segment by valgrind (using VG_(find_seginfo)()). > Looking at proc/XXX/maps, I get: > > 04000000-04017000 r-xp 00000000 03:03 557124 /lib/ld-2.3.5.so > 04017000-0401c000 rw-p 04017000 00:00 0 > 04026000-04027000 r--p 00016000 03:03 557124 /lib/ld-2.3.5.so > 04027000-04028000 rwxp 00017000 03:03 557124 /lib/ld-2.3.5.so > > Does anybody have an idea what can cause this? What particular aspect of that are you asking about? It looks OK to me; the r--p bit is the relro section (relocation read-only), which is read/write while relocations are being done and then gets changed to read-only. The rwxp is the rest of the data section. Paul. |
|
From: Julian S. <js...@ac...> - 2005-11-15 11:45:05
|
On Tuesday 15 November 2005 11:17, Paul Mackerras wrote: > Josef Weidendorfer writes: > > 1) There is a "strange function" with a single instruction "blrl". > > It is called quite often at the start of any code in /lib/ld.so, > > address 0x04027528; ld.so is mapped starting from 0x04000000. > > In the current PPC32 ELF ABI, there is a blrl instruction in the word > before the start of the GOT (global offset table). Shared libraries > use a bl GOT-4 to get the address of the GOT into LR in > position-independent code. I wouldn't consider the bl and blrl to > denote a function call. That would be nice. It's a bit like the the x86 idiom "call lbl; lbl: pop %reg" to get the current PC into %reg, which the x86 front end treats as a single entity. The problem is that the bl and blrl are in different BBs and so it's difficult to get the insn decoder to treat them as a single entity. I think the problem Josef was having is that although the bl is manifestly a call, the blrl is not obviously a return, and so callgrind's call-stack tracking stuff was seeing a lot of calls with no returns. > What particular aspect of that are you asking about? I think this is resolved now -- a query was being made to the wrong part of the system. J |