Gcc Map File Browser For Mac
I am considering putting together a free online tool for map file analysis. Something that accepted a gcc linker mapfile and showed a sortable data table and with a bar chart that lets you quickly see function sizes and addresses.
A few questions: - Does something like this exist already? I didn't find anything after a quick search.
Would people find this useful? - I'd probably use yahoo's datatable an chart tools which are based on flash. Is that a major barrier? Any other ideas for what the tool might show? For simplicity I don't think it would store any of the uploaded info, it would just parse the mapefile and show the results. Of the many, only appears to me to easier provide information at a glance than what's available now in the various ouput files.
Thus this would be fine to have. Plus a similar one for RAM usage (although that might get even more tricky). However, might be tricky to implement so that it will display legible/reasonable/relevant information with all sizes of programs (from 1-function to 10000-function) and all sizes of memories, and all sizes of displays.
Mind that legibility decreases with density of information and with need for scroll. But this all appears to be dependent on personal taste, so prepare yourself for quite a bit of controversy. Wek wrote: However, might be tricky to implement so that it will display legible/reasonable/relevant information with all sizes of programs (from 1-function to 10000-function) and all sizes of memories, and all sizes of displays. That's easy to solve, just provide an option to limit the number of symbols displayed. Combined with sorting, you'd get decent good control of the display. But its really a mute point, since there hasn't been enough interest to bother. More time for other stuff;).
D: sounds avrappavr-nm -size-sort sounds.elf. 000000f0 T dflashstartwriteactive 000000fa T vector1 0000010c T adpcmdecoder2 0000010e T adpcmdecoder1 00000110 T timeuartbit0 00000116 T dumpram 0000013c T dflashflushbuffer 0000014a T adpcmcoder 00000214 T main 0000021c T transmitflash 00000230 T vector8 000002d2 T dumpvars 00000318 T myspmroutine 00000324 T dumpflash 0000032e T help 0000037c T motortest 00000498 T playflash which is an ascending list of routine sizes - sure there's no bar graphs but I guess I could script something to output an increasing number of asterisks if really moved to. (clearly if I was looking for space savings I'd start with playflash ). Skeeve wrote: It's hard to feed a graph to another program. I don't want to start a huge debate, but that's a fairly pointless statement in this context.
Even if true, that statement doesn't diminish the usefulness of graphs as a way to visualize data. Of course it would be bad if a graph was the only output of avr-nm or something, but since that isn't the case we don't have much to worry about by.adding. graphs on top of parseable data. Now, no one may actually have a need for the graphs given the existing text representations, but that's a different argument.
Clawson wrote: found it Thanks, Cliff. A hour+ of reading. Well, from what I can read in that thread, it's not THAT bad, given a bunch of reviewers with strong opinions, and an immature beta product with code size limitations.;-) I have heard praises on their PIC Pascal which AFAIK is their original product, but given the present situation, if the guys won't die from hunger, they simply must try to make it on the 'majority' market, too. There also the roots of their business model. The website is far the nicest among the competitors, too.
It does not appeal to me personally, but in 21st century it is certainly a factor to count. Thanks again for the link. Sorry for hijacking the thread.
Oh, and if we vote, I think I already said yes for the sizes graph, no asterisks;-). Skeeve wrote: It's hard to feed a graph to another program.
I don't want to start a huge debate, but that's a fairly pointless statement in this context. Even if true, that statement doesn't diminish the usefulness of graphs as a way to visualize data. Of course it would be bad if a graph was the only output of avr-nm or something, but since that isn't the case we don't have much to worry about by.adding. graphs on top of parseable data. Now, no one may actually have a need for the graphs given the existing text representations, but that's a different argument.In the case at hand, I'm don't see that a graph would add all that much. Another dimension might change that, possibly size vs. Something else.
I see nothing wrong with having both approaches. Zealotry comes into play when one side is picked exclusively over the other. There are some tools that can make graphics based on text input only.
They're used in building a few of the graphics in the avr-libc user manual. I'm not terribly familiar with how they work, but I'm wondering if the output of avr-nm can be fed into those tools and a nice graph could be automatically built. If so, then it could be easily added as an additional build step in the Makefile. Eric, I downloaded Gnuplot and looked at the demos and also had a flick through the manual but the whole thing seems a bit 'heavy' for such a simple job - the tar.gz is 2.5MB apart from anything else.
I'll have a hunt round and see if I can find a simpler data-JPG (or similar utility) with open source. Failing that it must be fairly easy to do something with libjpeg and some rectangle drawing routines (the trickiest bit is probably rendering text onto the jpeg in a platform independent way) Cliff. Clawson wrote: I downloaded Gnuplot and looked at the demos and also had a flick through the manual but the whole thing seems a bit 'heavy' for such a simple job - the tar.gz is 2.5MB apart from anything else. I am messing with it, too, between lengthy compiles, and don't like it either. It's certainly a fine thing for what it's intended for - drawing x-y graphs.
I'll investigate this further, meantime, a small taster of what can be achieved (this is cca 1/3 of my program's code). JW Attachment(s). I'm kind of surprised it's proving so difficult to find someone who has previously put together a simple solution for this. Well, for most Unices, things like Perl or Python are usually around alraedy anyway. So it's not a big deal to use these scripting languages there. Windows simply has a different set of tools. I think, if at all, it would probably be better done with some kind of interactive tool, so you could e.g.
Provide 'tooltip' information when moving the cursor over some block. Also, this would allow for a scrollbar on the Y direction.
However, hacking something like that was simply beyond the time I've had available for this. Dl8dtl wrote: I'm kind of surprised it's proving so difficult to find someone who has previously put together a simple solution for this. Well, for most Unices, things like Perl or Python are usually around alraedy anyway. So it's not a big deal to use these scripting languages there. This is again a traditinal view.
With the present invent of 'boxed' Linux distros like Ubuntu intended primarily for mere users rather than cool.nix gurus, the development tools start to miss by default (OK interpreters like Perl and Python and Java may continue to be present, but gcc and kin is typically not installed by default). When I get home I'll check on my tiny Eee70x for perl and python.
Dl8dtl wrote: I think, if at all, it would probably be better done with some kind of interactive tool, so you could e.g. Provide 'tooltip' information when moving the cursor over some block. Also, this would allow for a scrollbar on the Y direction. However, hacking something like that was simply beyond the time I've had available for this.
That is why my original idea was to do this online with a free flash based graphing tool from Yahoo. It would provide interactive on the fly sorting, tool tips, and results limiting (so you could view just the top N results). Wek wrote: PS. OK, and what diagram-generating tool do.nices usually have?Tk can be used from Tcl and python. The canvas widget has a postscript method that will (duh) generate a postscript representation.
For my thesis diagrams, I generated encapsulated postscript directly. Pstopnm can convert postscript to raster scan. Pnmtowhatever can convert pnm to rather a lot of things. I'm pretty sure that python and Tk are ordinary. I'm not sure about the pnm tools. Tk is designed to show stuff.
There might be a way to generate postscript without showing a canvas on the screen, but I don't know it. Wek wrote: PS. OK, and what diagram-generating tool do.nices usually have?Tk can be used from Tcl and python. The canvas widget has a postscript method that will (duh) generate a postscript representation. For my thesis diagrams, I generated encapsulated postscript directly.
Pstopnm can convert postscript to raster scan. Pnmtowhatever can convert pnm to rather a lot of things. I'm pretty sure that python and Tk are ordinary. I'm not sure about the pnm tools.
Tk is designed to show stuff. There might be a way to generate postscript without showing a canvas on the screen, but I don't know it. Well, I'd bet, few to none of the listed (pstowhatever, tcl/tk, python) is available on the 'boxed' linuces I mentioned above, so these are none better than anything what needs to be installed on Win, either. The 2MB+ of that gnuplot thingy sounds like a bargain in this respect. Brad / Michael / JW, If this was done you need to bear in mind that the solution needs to work (or at least should be buildable) on both Windows and Linux platforms and that it cannot rely on a huge support library (like Python) that would bloat a delivery such as WinAVR for a tool that most people probably don't want or care about.
I just started writing something in plain C which will even include 8x8 (possibly larger?) font definitons and render onto a 24-bit BMP file (the world's easiest to create graphic file format?). So far the standalone Windows.exe is 28KB. What I don't propose to do is try to display this - all desktop systems have SOME way to view.BMP files. This does mean that there won't be a cursor and tooltips etc. Just a picture like the one on the Mikroe site: (that doesn't appear to offer interactivity - just a fixed image) Cliff.
Gcc Map File Viewer
Clawson wrote: I just started writing something in plain C which will even include 8x8 (possibly larger?) font definitons and render onto a 24-bit BMP file (the world's easiest to create graphic file format?). Do you intend to input the nm format, i.e. 'position size something name'? I would offer to make a few changes the I made recently, to output a similar list. It opens possibilites nm can not have, e.g. Filtering by sub-sections (ever wondered about usage of.progmem section?) Just that it's Pascal (primarily FreePascal, so with nil to little effort can be built on Linux or whatever), so it's been most probably frowned upon here.:- JW. If you write it in C, you could probably even (dynamically?) link against libbfd.a (part of binutils, which is part of WinAVR anyway) to read the ELF file directly.
That might be easier than parsing the output of another tool. All the c.NNNN labels in my output are supposedly module-internal ('static') functions. Their actual names could be resolved through debugging symbols (I believe). The tricky thing with using plain C is that plain C doesn't offer graphics, and using some platform-independant graphics option will get you back to where you came from. By now, the only related stuff that's already part of WinAVR would be Tcl/Tk (that's why I wrote Mfile using that toolkit). Dl8dtl wrote: If you write it in C, you could probably even (dynamically?) link against libbfd.a (part of binutils, which is part of WinAVR anyway) to read the ELF file directly. That might be easier than parsing the output of another tool.
Maybe, but it then certainly loses a great degree of flexibility. If it inputs a position-size-name list, in an unix-like chain of utilities could be reused for other purposes - e.g. To display similar graph for SDCC (which can't produce elf at the moment). On the other hand, the tool producing the list can then be easily recreated with different toolset, with different properties, etc. Dl8dtl wrote: All the c.NNNN labels in my output are supposedly module-internal ('static') functions. No - all static functions are output with their true name, with lowercase 't' as the 'flag'.
The 'c.whatever' are actually the result of using the PSTR macro; those are static data arrays, all declared with name 'c'. Note, that nm has no way of telling, in which input (sub-)section the 'function' was, so you can't distinguish.progmem. (constants) from 'genuine' functions (both are.text output section) - this information is lost during linking and is not present in.elf.
You should also go into the pains of go through the debug info to match symbols to their respective sources. In this regard, the link map is superior source of information - and it would be so generally, wouldn't the linker simply omit ALL the static symbols from the mapfile.
This could be one more reason to keep the data preparation and the graph drawing separate. Window's standard diagram generating tool in the bean counter category is called Excel - standard as far as paying extra for the privilege to mangle innocent number in unexpected ways is required. As for all the diagram demos, well, well, well. Nice demonstration of what I previously wrote. So now, why not first select a diagram type that shows 'something'? Like for example, to show how much of the flash is eaten by the largest functions in relation to the total used flash? That would, for example, call for a pie chart.
To avoid cluttering the chart I would go through the data to select the methods which together accumulate, let's say, 75% of the total used flash, but not more than, let's say, 15 functions. Whatever comes first when looking for the functions using 75%. All the rest would just be added up under the heading 'others'. Doing it is left as an exercise to those who want a diagram. Hint: gnuplot can't do pie charts. D: c makebmpavr-nm -size-sort -t decimal sounds avrapp timer1.o makebmp input 00 size=18, text = 00000018 r c.2127 input 01 size=46, text = 00000046 T timeuartbit input 02 size=102, text = 00000102 T vector19 input 03 size=146, text = 00000146 T setbaudtime input 04 size=250, text = 00000250 T vector1 input 05 size=272, text = 00000272 T timeuartbit0 input 06 size=560, text = 00000560 T vector8 largest = 560 scale = 1.19 and in the background creates a file called test.bmp which at the moment is the right dimension but all completely black because of. Quote: That's why I was going to do it online as a hosted solution.
Ah Web 2.0 generation thinking eh?;-) (fine until your not in range of the internet) By the way I'm kind of assuming that this would not be a standard option (say in the Mfile template) but an optional build option so the user would 'make graphs' or something to get them generated. I'm not sure everyone would want heaps of graphic images being created on every build and, for sure, they wouldn't want to get dragged into some interactive GUI tool until requested. On one of my Ubuntu systems I installed a 'boot profiler' that, on each boot, profiles where the milliseconds are being eaten and it's final output is a fairly large graph showing where the time was spent (in fact, as I mention it, maybe that has the tools for this job?). Anyway on a 4GB CompactFlash based system this started chewing it's way through the available space! EDIT: the thing I'm thinking of is 'apt-get bootchart' and the key component is bootchart.jar - so maybe forget that as an idea or can one rely on everyone having a JVM on both Linux and Windows? By the way I had intended to follow the MikroE model and have sizes ascending rather than descending but that's yet another artefact of Microsoft's 'upside down' Y axis.
If anyone is mad enough to trust un-verified.exe's ver 0.0.0.0.1 (which actually has even started to be version numbered) is attached. I've just got to move the source over to Linux and build it there to make sure that I haven't relied on anything MS/Windows but when you only include stdio.h I'd hope you can be pretty certain! Cliff Attachment(s). Michael, Well it's your choice - I'm not planning to produce anything but straight RGB.BMP (as I said, the easeist graphics format in the world (apart from the fact that it's upside down and rasters need to pad to 32 bit boundaries)). In Linux I imagine one could use convert from ImageMagick to make PNG or TIF or whatever you choose. But me, I'm sticking with BMP.
JW, Wow, that was quite a test. I fixed the image width at 768 pixels (to keep files smallish and to fit in most folks screens at 1:1).
Initially I made a 'guesstimate' and set 'LABELWIDTH' to 100 thinking 'that's bound to be enough isn't it?' But it was very soon evident that wasn't enough so this version has it set to 250. One of the things I plan is to truncate the label strings so there won't be any over-write and if the font has some ellipsis I'll replace the last visible character with that (if it doesn't I'll add one anyway) Cliff (the font I'm using is pulled straight out of the Linux kernel tree). Clawson wrote: Well it's your choice - I'm not planning to produce anything but straight RGB.BMP (as I said, the easeist graphics format in the world (apart from the fact that it's upside down and rasters need to pad to 32 bit boundaries)). In Linux I imagine one could use convert from ImageMagick to make PNG or TIF or whatever you choose. But me, I'm sticking with BMP.BMP is only the second easiest, but the pnm formats don't seem to be as popular. I only mentioned PNG because I saw the.jpg suffix on an attachment.
Curt, Yup I think you sold me on that solution. I downloaded the rebview in both Vista and Ubuntu and then output some 'nm' output into a test.txt and ran the script './rebview -w test.r'. On the Windows machine it worked like a dream. On the Linux system I got a.png with green bars created but sadly there was no text - so that would need a bit of work I guess - as you don't actually name a font in the script I don't know why it would have failed but maybe THAT is the problem? The fact you've got the PNG encoding and everything in the 0.5MB seems like a smallish cost to pay and the great thing would be that everyone who used WinAVR would have the ability to get interested in Rebol if they liked (though maybe the Tcl used by Mfile suggests that people don't use the supplied utilities for much more than the task they are delivered to provide?) Cliff Attachment(s).
Mac Build Gcc
talk about complicated - I finally managed to get the sources of Zlib and libpng to build in VC 9 and I found some useful looking source at: so I 'borrowed' bits of that and grafted into my own program to finally create a 'makepng.exe' that works just like makebmp (in fact the core is the same so I'm just calling this V1.2 of the same thing). This 200K.exe is the 'debug' build because, for reasons that yet allude me, when I try to build 'release' MASM barfs on some of the.asm files in Zlib. I statically linked everything so this is completely stand-alone. I'm hoping it'll be an easier build in Linux! Cliff EDIT: I found the build options to use C rather than Asm so the.exe including the PNG encoding is 88K Attachment(s). D: c makepng Debugavr-nm -size-sort -t decimal sounds avrapp timer1.o 00000018 r c.216 T timeuartbit 00000102 T vector6 T setbaudtime 00000250 T vector1 00000272 T timeuartbit0 00000560 T vector8 D: c makepng Debugavr-nm -version GNU nm (WinAVR 20090313) 2.19 Copyright 2007 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or (at your option) any later version.
This program has absolutely no warranty. In the version I just posted there's a new command line paramter '-T ' which will filter the nm output on the column after the size for the given character so normally you'd use. Oh and if anyone has a copy of MS VC 8 Express then all the project files to build the Windows.exe are in: It's a 2.3MB download but that's mainly because contains copies of both the libpng and zlib source.
I have this in d: c makepng, d: c libpng-1.2.37 and d: c zlib - as there may be absolute paths embedded it probably needs to be in the same place to build (which is where subst comes in handy;-)). The 'solution' file that pulls everything together is the makepng makepng.sln file, so just load that into Vis Studio Rather amusingly in Ubuntu (where zlib and linpng(12) are probably already installed or can easily be got with apt-get) you only actually need. Cliff, the new graph is very pretty.;-) is the new version of the map checking utility I have thrown together, with some readme, a.bat file generating a few pictures (the masochist types can just use make for that:-P - note that I am using the 'sort' program (what a @#$%^ idea to call programs to be confused with ordinary words), which is distributed together with WinAVR), and a rudimentary html file, just as a very rough example what would I expect to have. Some pictures attached here. Jan Attachment(s). Dbvanhorn wrote: What values would you suggest in the config for an ATMEGA2560?Well, I'm not sure if you meant my checkmap utility, but if yes - the idea is that a config will be written for the internal resources of each avr and then some magic in make would check the appropriate model. I intended this as one of the small enhancements of progmem/far management.
However, I am now too busy with the work which pays the bills to sit down and create all the zillion config files needed. If I get to it, I'll start with the ATMega256x, I promise (anyway, that's one of the targets what I am working at now, and that's for which I needed all the progmem-far stuff I plan to share).
Dear, I need a newer version of gcc to compile libgimli ( ) under mac os x 10.7.4. I already tried macports, homebrew and compiling from hand, but I keep getting errors. Below is the error if I use Homebrew.
How should I proceed? Hecking for x8664-apple-darwin11.4.0-gcc. /private/tmp/homebrew-gcc-4.7.0-OLFi/gcc-4.7.0/build/./gcc/xgcc -B/private/tmp/homebrew-gcc-4.7.0-OLFi/gcc-4.7.0/build/./gcc/ -B/usr/local/Cellar/gcc/4.7.0/gcc/x8664-apple-darwin11.4.0/bin/ -B/usr/local/Cellar/gcc/4.7.0/gcc/x8664-apple-darwin11.4.0/lib/ -isystem /usr/local/Cellar/gcc/4.7.0/gcc/x8664-apple-darwin11.4.0/include -isystem /usr/local/Cellar/gcc/4.7.0/gcc/x8664-apple-darwin11.4.0/sys-include checking for suffix of object files. Configure: error: in `/private/tmp/homebrew-gcc-4.7.0-OLFi/gcc-4.7.0/build/x8664-apple-darwin11.4.0 /libgcc': configure: error: cannot compute suffix of object files: cannot compile See `config.log' for more details.
Apple Footer. This site contains user submitted content, comments and opinions and is for informational purposes only. Apple may provide or recommend responses as a possible solution based on the information provided; every potential issue may involve several factors not detailed in the conversations captured in an electronic forum and Apple can therefore provide no guarantee as to the efficacy of any proposed solutions on the community forums. Apple disclaims any and all liability for the acts, omissions and conduct of any third parties in connection with or related to your use of the site.
All postings and use of the content on this site are subject to the.