Patch: Simulator for 64-bit CPU now writes correct gmon.out files

[Mike Frysinger]

On Wednesday 20 February 2013 05:21:41 Holger Teutsch wrote:
> On Tue, Feb 19, 2013 at 7:35 PM, Mike Frysinger wrote:
> > On Tuesday 19 February 2013 08:03:04 Holger Teutsch wrote:
> > > On Tue, Feb 19, 2013 at 8:47 AM, Mike Frysinger wrote:
> > > > On Saturday 09 February 2013 11:40:35 Holger Teutsch wrote:
> > > > > GDB's simulator as of 7.5.1 did not write out correct "gmon.out"
> > > > > files for 64-bit CPUs.
> > > > > 
> > > > > The attached patch adds this functionality.
> > > > 
> > > > your patch changes it so it uses the old BSD style header for 32bit
> > > > targets but the new BSD4.4 style header for 64bit targets (going by
> > > > gprof/gmon.h). there's no reason to diverge like that.  i would keep
> > > > them both with the old
> > > > style (since it's much simpler).
> > > > 
> > > > if you really wanted to update things, i would say convert it to use
> > > > gmon style output.  if you wanted super extra brownie points, the
> > > > sim-profile.c and
> > > > gmon_io.c code really should be unified :).
> > > 
> > > I will go the gmon way. I will borrow and use verbatim binutil's
> > > gprof/gmon_out.h  and gprof/gmon_io.h.
> > > Then I will write a sim_gmon_io.c that implements the necessary
> > > functions as close to the original as
> > > possible.
> > > 
> > > Hopefully this qualifies for 1 brownie point. I leave the others to the
> > > maintainer of gprof 8-)
> > 
> > well, ideally the gmon code would get moved to a common location (maybe
> > libiberty/ or bfd/) and then both gprof and the sim would use that. 
> > would require posting a mini-proposal to the binutils list to see if
> > anyone has an
> > opinion.
> 
> I looked through the code of gprof.
> Unfortunately the files gmon_io.c + hist.c are not generic. The include up
> to 12 headers specific to gprof
> and communicate with gprof through global variables. Most of the stuff is
> related to reading and transforming
> data into gprof's internal structures.
> 
> So, to go this way
> - gmon_io.[ch] have to be splitted into a read and write related part
> - hist.[ch] likewise
> - the interfaces have to be cleaned up so they are no longer gprof specific
> - the write related part can be moved elsewhere
> 
> Honestly, I don't think that sharing ~100 lines of code warrants this
> effort.

the issue is that i don't want to re-implement logic for writing gmon files.  
i'm not an expert in the format, and we already have a project whose entire 
job it is to manage these files.

perhaps that means abstracting out the core funcs and rebasing gprof & sim on 
top of that.

if it's too much work, then i'd suggest the simple route -- only write out the 
BSD old style header like we currently do.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://sourceware.org/pipermail/gdb-patches/attachments/20130220/ae3fd214/attachment.sig>