From: Daniel H. <dan...@li...> - 2007-11-26 14:08:43
Attachments:
jitrecord_padding.patch
|
Hello everybody, due to the integration process of the JIT support I have implemented the TODO to align the JIT records in the JIT dump file to 8-byte boundaries. When the patch is accepted I will commit the changes to the JIT_SUPPORT branch. Thanx in advance. Kind regards, Daniel Hansel |
From: Daniel H. <dan...@li...> - 2007-11-26 21:07:59
Attachments:
jitrecord_padding.patch
|
Hello everybody, due to the fact that I did not sent the patch including all parts of my implementation; here is the complete patch. Please review again. Thanx in advance. Kind regards, Daniel Hansel |
From: Philippe E. <ph...@wa...> - 2007-11-29 11:46:31
|
added cc to the mail list On Wed, 28 Nov 2007 at 21:18 +0000, Maynard Johnson wrote: > Philippe Elie wrote: > [snip fwrite(.., 0 elem);] > Phil and Daniel, > I was tied up most of the day and didn't get to looking into this > problem until very late. I still had the same problem even with the > above changes you suggested, Phil. I checked out OProfile JIT_SUPPORT > branch from Nov 24 and that version works OK, but a checkout from Nov 26 > fails. Phil, this was after you put in the code to make anon samples > relative to the start of the mapping and for multiple section support. > I'm wondering if this is a difference between Sun's JRE and IBM's JRE. Right, I get this trouble with the IBM jre now. > > I'll investigate further tomorrow, but my preliminary debugging points > at possibly two problems. The set_offset function in libpp/profile.cpp > is being called three times on the same op_bfd for the .jo file, > changing the start_offset each time it's called. That's because in my > testing environment (with IBM 1.5 JRE), I get three anonymous sample > files for the java process, each with a different anonymous memory > mapping. But it appears there's another problem beyond that. I'm not > sure the start_offset is being calculated correctly. Sorry I don't have > more info than that. Just ran out of time today. Yes, there is two problems: 1) set_offset() can set start_offset to a negative value so we can call get_symbol_range() and result which look like 0xffffffde-0x00000234, 2) the problem of multiple mapping, the value to shift symbol value are not contant but depend from what mapping the symbol is coming. There is two way to fix it: 1) relayout the elf file to create dummy symbols at start of each mapping, so in post profile tools we will need to only do the normal fixup for multiple section, but actually I don't think we can ask the vm to get the mapping start address, only daemon know it. 2) in set_offset() do nothing but pass to the abfd the start vma of this mapping, record start vma offsets of each mapping in the abfd object, and when doing translation of symbol offset to vma, fixup correctly the vma. 1) will be cleaner but I don't think it's possible to implement, I'm trying 2) now. -- Phe |
From: Philippe E. <ph...@wa...> - 2007-11-29 19:21:49
Attachments:
support-multiple-mapping.patch
|
On Thu, 29 Nov 2007 at 12:41 +0000, Philippe Elie wrote: > added cc to the mail list > > On Wed, 28 Nov 2007 at 21:18 +0000, Maynard Johnson wrote: > > > I'll investigate further tomorrow, but my preliminary debugging points > > at possibly two problems. The set_offset function in libpp/profile.cpp > > is being called three times on the same op_bfd for the .jo file, > > changing the start_offset each time it's called. That's because in my > > testing environment (with IBM 1.5 JRE), I get three anonymous sample > > files for the java process, each with a different anonymous memory > > mapping. But it appears there's another problem beyond that. I'm not > > sure the start_offset is being calculated correctly. Sorry I don't have > > more info than that. Just ran out of time today. > > Yes, there is two problems: > > 1) set_offset() can set start_offset to a negative value so we can call > get_symbol_range() and result which look like 0xffffffde-0x00000234, > > 2) the problem of multiple mapping, the value to shift symbol value are not > contant but depend from what mapping the symbol is coming. > > There is two way to fix it: > > 1) relayout the elf file to create dummy symbols at start of each mapping, > so in post profile tools we will need to only do the normal fixup for > multiple section, but actually I don't think we can ask the vm to get > the mapping start address, only daemon know it. > > 2) in set_offset() do nothing but pass to the abfd the start vma of this > mapping, record start vma offsets of each mapping in the abfd object, and > when doing translation of symbol offset to vma, fixup correctly the vma. > > 1) will be cleaner but I don't think it's possible to implement, I'm > trying 2) now. Patch attached, can you test it Maynard ? I'm unsure it it's sufficient if one mapping is splitted into multiple section through our hole detection in opjitconv. -- Phe |
From: Daniel H. <dan...@li...> - 2007-11-29 13:31:51
Attachments:
jitrecord_padding.patch
|
Hello everybody, due to fact that fwrite() and fwrite_unlocked() will return 0 if nothing is written or an error has occurred I inserted now an additional check for that case. Thanx to Philippe for that information. Kind regards, Daniel |