Profiler for gcc


Moderators: simonsunnyboy, Mug UK, Zorro 2, Moderator Team

Captain Atari
Captain Atari
Posts: 376
Joined: Tue Sep 21, 2004 11:11 am
Location: Poland

Profiler for gcc

Postby jury » Tue Sep 25, 2018 11:57 am

I use Vincent's cross toolchain and so far it works great. Now I would like to use gprof to check some stuff.
I compile the project with -pg option, like:

Code: Select all

gcc -Wall -c -pg source.c
and it compiles fine.
But during linking process all I get is:

Code: Select all

multiple definition of `___writev'
/usr/m68k-atari-mint/lib//libc.a(gmon.o):gmon.o:(.text+0x0): first
defined here
collect2: ld returned 1 exit status"

Any clues how I could make this to work?

Hardware Guru
Hardware Guru
Posts: 2110
Joined: Sat Sep 10, 2005 11:11 am
Location: Kosice, Slovakia

Re: Profiler for gcc

Postby mikro » Tue Sep 25, 2018 1:28 pm

I'm not sure whether it fixes the problem but maybe you need to use libc_p.a from mintlib instead of libc.a. Unfortunately it is not compiled by default, i.e. not available on

Atari Super Hero
Atari Super Hero
Posts: 981
Joined: Sun Aug 03, 2014 5:54 pm

Re: Profiler for gcc

Postby ThorstenOtto » Tue Sep 25, 2018 1:30 pm

jury wrote:Hi
Any clues how I could make this to work?

I think you are using an older version of mintlib:

There is no global symbol __writev in gmon.c anymore.

Captain Atari
Captain Atari
Posts: 493
Joined: Wed Oct 24, 2007 7:52 pm
Location: France

Re: Profiler for gcc

Postby BlankVector » Tue Sep 25, 2018 7:24 pm

Unfortunately I have never tried gprof (or I forgot), so good luck.
Subscribe to my Vretrocomputing channel on YouTube and Facebook. Latest video: Save and restore the video mode in assembly language on Atari ST.

User avatar
Eero Tamminen
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2048
Joined: Sun Jul 31, 2011 1:11 pm

Re: Profiler for gcc

Postby Eero Tamminen » Wed Sep 26, 2018 7:53 am

I'd recommend using Hatari debugger's profiling functionality instead:
* It doesn't have overhead like -pg has and it's more accurate (on ST/STE, cycle accurate as Hatari emulation for them is cycle accurate)
* it can give much more information (callgraphs for instruction counts & cycle counts, cycle counts per memory-address...)
* You don't need to recompile anything, binaries just need to be unstripped (have debug symbols)

See: ... #Profiling

To see function level information, it's enough to compile binaries with debug symbols, as Hatari v2.1 debugger automatically loads GCC's a.out and Atari DRI/GST debug symbols from the binaries.

Main issues one needs to be aware with function level profiling info is quality of debug symbol data. E.g. some MiNTlib versions strip debug symbols away from performance-wise important functions, in which case noticeable perf costs get instead assigned to functions preceeding those. And if loops have labels (debug symbols), call/visit counts may cause some confusion. If in doubt, all these issues can be resolved by looking at the profiler disassembly output (assumes one is familiar with what function calls look like at m68k assembly level).

Social Media


Return to “Coding”

Who is online

Users browsing this forum: No registered users and 8 guests