From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: [PATCH] gcov: Support gcc 4.7 Date: Tue, 18 Jun 2013 15:53:21 +0100 Message-ID: <51C07461.606@eu.citrix.com> References: <1371457748.9654.3.camel@hamster.uk.xensource.com> <1371465779.23802.31.camel@zakaz.uk.xensource.com> <1371466006.9654.15.camel@hamster.uk.xensource.com> <1371466192.23802.37.camel@zakaz.uk.xensource.com> <1371565974.12598.39.camel@hamster.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1371565974.12598.39.camel@hamster.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Frediano Ziglio Cc: Matthew Daley , Christoph Egger , Ian Campbell , Miguel Clara , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On 06/18/2013 03:32 PM, Frediano Ziglio wrote: > On Mon, 2013-06-17 at 11:49 +0100, Ian Campbell wrote: >> On Mon, 2013-06-17 at 11:46 +0100, Frediano Ziglio wrote: >>> Perhaps a simple easy solution would be to allow privileged domains to >>> read/write arbitrary memory from Xen (write to reset counters). >> >> "Arbitrary memory" would be a very hard sell. >> >> If all these counters could be constrained to pages which contains these >> counters and nothing else then that might be a possibility to consider. >> >> Ian. >> > > It depends on how this would be implemented. A future option of gcc > could help at least having everything in contiguous memory regions. > > The fact that these information are generated by the compiler does not > help that much. Every version could change the format "slightly" but > enough to make Xen core when such information are requested! > > Actually they changed format for these version of gcc: > - 3.3 > - 3.4 > - 4.7 > > And honestly I still don't understand clearly why they changed for gcc > 4.7! Probably not for a C feature but to support C++ templates and > comdat. A "smart" preprocessor sit in the middle of gcc and gas that > process assembly generated, check for structures and put everything in > different sections could really help... but is not that easy project! > Another similar way would be to parse the xen-syms output file and > generate needed blob/code. Quite interesting challenge (I did more > terrible things then this) but I don't thing that Citrix would agree. > Possibly a safe thing to do would be in the code to check that compiler > is really gcc and that we can support the version that is compiling, > just to make sure. But is also true that this feature is a debug one > disabled on production so I don't know how worth would be. > > Not speaking of clang support, currently quite hard (the structures are > less documented, the code hooks destructors path which is not safe to > call from Xen code which is not expected to terminate). Doesn't Linux have gcov support via lcov? Do they have to deal with this stuff as well, or is there a generic way to deal with it? -George