From: Suravee S. <sur...@am...> - 2011-05-06 04:38:05
|
Hi Maynard, The patch looks ok. Sorry for delay reply. Suravee On 05/05/2011 02:33 PM, Maynard Johnson wrote: > Suravee, > Below is another testimonial that the patch I asked you to review resolves this > type of problem. The case that Antonio ran into is different from the original > error scenario (the '__SDA_BASE_' symbol). In discussions I've had with some of > my colleagues, we feel it's very likely that Antonio's problem is caused by > either a compiler bug or some too-clever coding tricks (in python?) that's > resulting in the odd-looking symbol value of 0x40b1acbb for the symbol > '__gcmap____module_cache_module_10___PyPy_dg_strtod_2278'. So the more I think > about it, the more confident I am that the current algorithm for calculating a > symbol's 'end' value is correct, and if it happens to be less than 'start', then > we've encountered one of these odd exceptions where it's safe to simply set > symbol size to 0. If you (or anyone else) disagrees, I'd be happy to discuss it > further. If not, please give your 'ack' to the patch, and I'll go ahead and > commit it. > > Thanks. > > -Maynard > > > On 05/05/2011 3:18 AM, Antonio Cuni wrote: >> On 04/05/11 21:36, Maynard Johnson wrote: >> >>> Antonio, >>> It's a bug in opreport. Please see the April 5 posting (from me) to the >>> oprofile list with the subject line of: >>> "[PATCH] Fix symbol size problem that causes "start> end" erorr" >>> >>> From the name of the offending symbol and the fact that its size is 0, I'm >>> assuming this symbol (like the '__SDA_BASE__' symbol referred to in my post) >>> is a linker-defined symbol. I would appreciate your testing this patch and >>> letting me know if that resolves the problem (without the use of the >>> '--exclude-symbols' workaround). >> Hello Maynard, >> >> yes, I can confirm that with your patch, opreport -l works fine. Thank you >> very much! >> >> ciao, >> Antonio > |