This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: Patch: Simulator for 64-bit CPU now writes correct gmon.out files
Mike,
On Wed, Feb 20, 2013 at 7:47 PM, Mike Frysinger <vapier@gentoo.org> wrote:
> 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
It would go for the simple way now. May be I find more time for the
larger rework later.
Nevertheless I would seriously consider the BSD44 header for the 32bit
case as well.
In particular for simulators it's quite useful to pass the profile
frequency to gprof and that is not available in the old BSD header.
The old BSD header has 3 fields and the BSD44 header as 5. So the
increase in complexity looks manageable to me.
- holger