Sometimes I want to look up the implementations of functions in the stdlib, I've downloaded the sourcecode, but it's quite messy.
Just greping is not really suitable because of the many hits.
Does anyone know a webpage doxygen style that has the documentation.
The same goes for the linux kernel.
Thanks
You should check if your distribution is using the vanilla GLIBC or the EGLIBC fork (Debian and Ubuntu have switched to EGLIBC EDIT: they switched back around 2014).
Anyway, the repository browser for GLIBC is at http://sourceware.org/git/?p=glibc.git
http://code.woboq.org/userspace/glibc/, posted by #guruz below, is a good alternative.
The source is a bit complicated by the presence of multiple versions of the same files.
How about this for libc documentation? And perhaps this for the kernel? There is also Google Code search; here is an example search.
More on Google Code Search You can enter search queries like this: package:linux-2.6 malloc for any references to malloc in the linux-2.6 kernel.
Edit: Google Code search is now shut down. But you can access the git repo at http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git and it has search as well.
You can try http://code.woboq.org/userspace/glibc/
It has nice navigation/hilighting similar to an IDE.
To help navigate the source to glibc, perhaps try something like ctags or cscope?
Note: I get dumber every time I look at the glibc source, so please be careful! :)
If you are using GNU C (glibc), the functions (beyond the GNU extensions) follow the POSIX standard as far as their arguments, implementation, failure and return values. If you want to peek under the hood of static members, you'll have to look at the code.
Every push (that I can remember) to try and adopt something like Doxygen for glibc was rejected for the following reasons:
Redundant, POSIX already documents almost everything thats exposed, as well as man and info pages.
Too much work initially
More work for maintainers
As far as the kernel goes, Linux does use a system very similar to Doxygen called Kerneldoc.
You can also get actual Doxygen-generated docs from http://fossies.org/dox/glibc.
Related
We're using Greenhills Multi IDE and Greenhills Debug Probe to program and debug our target system (a Coldfire based, bare metal system). Currently I flash the target using the IDE debugger GUI, but I would prefer to use a command line interface to do it.
The documentation is fairly sketchy, and only gives a very simple example. As far as I can tell I should be able to use grun with gflash to do this, but I'm having a hard time figuring out which GUI fields map to which grun options. Anyone with any experience of this?
Basically I need to be able to specify (see image above):
Flash device (this one I've got figured out I think)
Base address
Image file (we use raw images)
Offset in flash
Alternate RAM base
Alternate flash utility
Possibly also alternate MBS script
Any tips, tricks, or pointers to better documentation than the standard GHS one? Would be much appreciated!
Is below screenshot from debugger command reference is of any help? You can use it to download your source on HW. I will be able to share more details is this helps. Or you can share your solution if you had already found it.
I used mpadmin for this purpose.
mpadmin -update <IP-addr_of_your-probe | -usb> firmware.frm
Currently I am trying to use Magma to do matrix operation on GPU, however, I found few documents about it. The only thing I can refer to is its testing program and the online generated document(here), which is not convenient to use. And the user guide seems outdated.
If you look here, getri and potri are supported.
I'd like to be able to Alt-Click an instance variable (or a method) as part of the program i created and read what it's purpose is.
The fact that Xcode is telling me the class variable is declared at - is nice but not enough. In this case i'd like to see custom text i typed to describe what an asset really is. Additionally type of the ivar would also be useful to know.
How can this be done? In this case, i wonder what exactly did i mean by assets
I specifically wonder if this information can be viewed from inside Xcode, similar to how Eclipse shows JavaDoc content.
You would need to create a documentation set for your project and install it in Xcode. appledoc can help you with this. This is a command-line tool that can generate documentation in Apple's style from specially formatted comments in your headers. You can also integrate this into your build process with a run script build phase, so that documentation is always up-to-date.
For small projects, it's usually not worth the effort though and you're probably better off just adding comments to your header files and jumping there with Cmd-click (Ctrl+Cmd+left-arrow to go back to where you came from).
You'll probably want to take a look at Apple's documentation on Documentation Sets as well as their article on generating doc sets using Doxygen. The latter is based on Xcode 3.x, so how relevant it is is somewhat questionable, but it'd be a good idea to take a look nonetheless.
That said, if you decide to use Doxygen (alternatives like HeaderDoc can be used for documentation, but I'm not sure what's available to you as far as creating doc sets goes), it looks like the main point is you'll want to throw GENERATE_DOCSET=YES into your Doxyfile (or whatever you decide to call it). After that, you'd just throw the results into ~/Library/Developer/Shared/Documentation/DocSets (according to Doxygen's documentation). I don't know whether this works in Xcode 4.x - it's worth a shot though, and it'd be nice to hear back on it.
Note: most of this was based on this answer by Barry Wark. Figure credit is due there, since I wouldn't have bothered looking into this were it not for his answer.
this is my first post, and it covers something which I've been trying to get working on and off for about a year now.
Essentially it boils down to the following: I have a copy of newlib which I'm trying to get working on an LPC2388 (an ARM7TDMI from NXP). This is on a linux box using arm-elf-gcc
The question I have is that I've been looking at a lot of the tutorials talking about porting newlib, and they all talk about the stubs (like exit, open, read/write, sbrk), and I have a pretty good idea of how to implement all of these functions. But where should I put them?
I have the newlib distribution from sources.redhat.com/pub/newlib/newlib-1.18.0.tar.gz and after poking around I found "syscalls.c" (in newlib-1.18.0/newlib/libc/sys/arm) which contains all of the stubs which I have to update, but they're all filled in with rather finished looking code (which does NOT seem to work without the crt0.S, which itself does not work with my chip).
Should I just be wiping out those functions myself, and re-writing them? Or should I write them somewhere else. Should I make a whole new folder in newlib/libc/sys with the name of my "architecture" and change the target to match?
I'm also curious if there's proper etiquette on distribution of something like this after releasing it as an open source project. I currently have a script which downloads binutils, arm-elf-gcc, newlib, and gdb, and compiles them. If I am modifying files which are in the newlib directory, should I hand a patch which my script auto-applies? Or should I add the modified newlib to the repository?
Thanks for bothering to read! Following this is a more detailed breakdown of what I'm doing.
For those who want/need more info about my setup:
I'm building a ARM videogame console based loosely on the Uzebox project ( http://belogic.com/uzebox/ ).
I've been doing all sorts of things pulling from a lot of different resources as I try and figure it out. You can read about the start of my adventures here (sparkfun forums, no one responds as I figure it out on my own): forum.sparkfun.com/viewtopic.php?f=11&t=22072
I followed all of this by reading through the Stackoverflow questions about porting newlib and saw a few of the different tutorials (like wiki.osdev.org/Porting_Newlib ) but they also suffer from telling me to implements stubs without mentioning where, who, what, when, or how!
But where should I put them?
You can put them where you like, so long as they exist in the final link. You might incorporate them in the libc library itself, or you might keep that generic, and have the syscalls as a separate target specific object file or library.
You may need to create your own target specific crt0.s and assemble and link it for your target.
A good tutorial by Miro Samek of Quantum Leaps on getting GNU/ARM development up and running is available here. The examples are based on an Atmel AT91 part so you will need to know a little about your NXP device to adapt the start-up code.
A ready made Newlib porting layer for LPC2xxx was available here, but the links ot teh files appear to be broken. The same porting layer is used in Martin Thomas' WinARM project. This is a Windows port of GNU ARM GCC, but the examples included in it are target specific not host specific.
You should only need to modify the porting layer on Newlib, and since it is target and application specific, you need not (in fact probably should not) submit your code to the project.
When I was using newlib that is exactly what I did, blew away crt0.s, syscalls.c and libcfunc.c. My personal preference was to link in the replacement for crt0.s and syscalls.c (rolled the few functions in libcfunc into the syscalls.c replacement) based on the embedded application.
I never had an interest in pushing any of that work back into the distro, so cannot help you there.
You are on the right path though, crt0.S and syscalls.c are where you want to work to customize for your target. Personally I was interested in a C library (and printf) and would primarily neuter all of the functions to return 0 or 1 or whatever it took to get the function to just work and not get in the way of linking, periodically making the file I/O functions operate on linked in data in rom/ram. Basically without replacing or modifying any other files in newlib I had a fair amount of success, so you are on the right path.
I cannot use the most recent dev Pharo release because of some strange issues with the compiler built into Pharo. Well. I was wondering if there is a quick way to install all the nifty extras into Pharo that the core image misses, as compared to the dev image.
With all non-core Pharo images come a script which was used to build that image. Just edit that file and drag&drop it on a new core.
You could also tell me what you don't like in the Pharo images so that I can enhance them.
There is also the script I published on the Pharo wiki that I use to build my images:
http://code.google.com/p/pharo/wiki/ImageBuildScripts
Of course it is very specific to my preferences and needs, but you can take it as an example and adapt it to your own needs.
CommandShell works with Pharo 9.10.10. You will hit several errors as you try to load the package due to Pharo lacking MVC, but you can simply proceed past the first bunch and abandon the last one (that tries to actually open a CommandShell in Morphic). At that point, you'll have a class called PipeableOSProcess that can be used very easily to grab output. For example:
(PipeableOSProcess command: 'ls /bin') output
will return the contents of your bin directory as a string.
Ok, OB itself can be easily downloaded using ScriptLoader loadSuperOB.
Damien adds (from comment below):
The problem with that approach is that nobody really maintains it.
Moreover, you miss some configuration steps to enhance the use of OB
(for example, you won't have the OB-based browsers if you ask for the
senders of a message from a workspace)