Looking at the manuals, objdump and nm have overlapping features.
When would you use each one? What was the original purpose of each command?
They have no similar parameters.
nm lists file symbols, while objdump can show a lot of different information about files. objdump can shows symbols too, and it is explicitly noted in the manpage that "This is similar to the information provided by the nm program, although the display format is different."
It seems like nm is posix, so available in non-gnu platforms.
http://pubs.opengroup.org/onlinepubs/000095399/utilities/nm.html
I see for example that OSX doesn't come by default with objdump, but provides "otool" , which offers some of the same features "objdump" offers on linux.
So I guess you would use nm if really all you want is look at symbol tables or similar tasks, and you care about portability of your script. For some other tasks, such as looking into the debug info of a file, objdump might be more appropriate.
Related
As I know, GCC has this website to figure out the relationship between different flags using while optimization. GCC example website. Like fpartialInlining can only be useful when findirectInlining is turned on.
I think the same thing would happen in clang, in other words, I think the different passes may have this kind of dependcy/confilcts relationship in LLVM(CLANG).
But after checking all the document provided by developers, I find it just say something about the functionality in these passes. LLVM PASS DOC
So my question can be divided into 2 parts I think:
Does the dependency exists in LLVM PASS or there is no such dependency/conflicts
If there is, how can I find them.
You can find which passes are using in which optimization levels by clang while compiling any c or c++ code with clang and try to figure out dependencies. For example:
clang -O2 --target=riscv32 -mllvm -debug-pass=Structure example.c
(You can use also -debug-pass=Arguments instead of -debug-pass=Structure. It depends readability.)
this will give which passes used by clang at 2. optimization level for riscv32 target. If you don't give a target it sets default as your host machine target, and keep in mind that some used passes changes related to different targets at same optimization levels.
I need to get full Clang warnings list. With Descriptions. For iOS.
I've seen just a list of warnings here
Clang Warnings
But there is no description.
Is there any place where i can get full list of Clang warnings with the description?
I realize this is an old question, but a complete list of warnings, along with the text printed for each one, can be found in the Clang Documentation.
(Note: This answer is now outdated.)
There's a neat project that shows the flags alongside their warning messages:
https://github.com/NSHipster/fuckingclangwarnings.com
While these are not comprehensive explanations in all cases, it is very helpful, especially when you want to switch off specific warnings.
The project hasn't been updated in a while and is probably missing a few new warnings. You could also dive into Clang's source code. I haven't worked with it in a while, but I can tell you where to start:
Clone the Clang repository
Browse to /include/clang/Basic/Diagnostic.td. This file includes a couple of other .td files which contain the various warnings, though I'm not sure if all of them are publicly available, and I think their external names are prefixed, depending on their category. I suggest searching for a known warning (or its description) to solve the puzzle.
Another interesting file is /include/clang/Driver/Options.td, which includes the texts you get using the help command, if I recall correctly.
The [current] accepted answer is correct. clang/clang++'s documentation up on the website doesn't necessarily reflect the supported options in the code. As the old phrase goes, "the source code is the documentation" :/..
One thing that will help with finding options is grepping the source code for DiagGroup. For example, the following demonstrates an attempt at grepping for sign-compare, aka -Wsign-compare, using a pared down clang 7.0.1 source checkout:
$ grep --include \*.td -r sign-compare . | grep DiagGroup
tools/clang/include/clang/Basic/DiagnosticGroups.td:def SignCompare : DiagGroup<"sign-compare">;
While discussing OpenCOBOL being utilized for FastCGI, I posted that replacing
#include <stdio.h>
with
#include <fcgi_stdio.h>
should exhibit no behaviour change for the vast majority of programs that don't care to call
FCGI_Accept()
Did I lie? Are there issues to consider? I'll admit to having not gone over sources yet, only docs from the website.
EDIT: 2013-03-08
I've done some experiments, and the statement is proving positive, but lack sufficient evidence to advertise the statement as true. I'd still appreciate any insider information.
As fcgi_stdio.h is redefining many stdio symbols to its own set of FCGI_* symbols, there will with certanity be some differences. Fastcgi also offers the possibility to #define NO_FCGI_DEFINES though, which lets you use both sets - although you'd have to be explicitly specifying the FCGI_ prefix.
I was just thinking about adding a way to determine which set is to use at runtime to be able to use the same binaries online and from cli, but thinking further about it I'll rather go with two make targets.
Also, compiling with libfcgi-dev v2.4.0 I seem to run into blank output in conjunction with -ldl / dlopen() although both binaries link to the same libfcgi.so.0...
--
tl;dr if you want to use dlopen() and see the output on stdout/stderr, don't #include <fcgi_stdio.h> (without defining NO_FCGI_DEFINES)
There are commands to list all functions in the program in gdb, but I did not find any untilities or gdb command/syntax to just list symbols in a particular shared library. nm doe s not work on arm7 shared lib. Any idea how to do it?
nm works fine on shared libraries... as long as they aren't stripped. If the library you're attempting to look at is stripped, neither nm nor gdb will show function names. If you're just interested in the Objective-C bits, class-dump-z is a good option. (you can get the same information from otool but it's less pretty)
I'm compiling library for a private project, which depends on a number of libraries. Specifically one of the dependencies is compiled with Fortran. On some instances, I've seen the dependency compiled with g77, on others I've seen it compiled with gfortran. My project then is ./configure'd to link with either -lg2c or -lgfortran, but so far I've been doing it by hand.
If it is possible, how can I find out, from looking into the dependent library (via e.g. nm or some other utility?), whether the used compiler was g77 (and then I'll use -lg2c in my link options) or gfortran (and then I'll use -lgfortran)?
Thanks in advance!
nm filename | fgrep ' __g77'
will give results if g77 was used, meanwhile
nm filename | fgrep '##GFORTRAN'
will give results if gfortran is used.
You need to grep for something, in the output of nm filename, that indicates whether g77 or gfortran was used. In most cases, if the library does at least input-output in one place, it will call libg2c or libgfortran and you will notice a symbol with g77 in it, or gfortran. So, your best bet is to use grep:
nm filename | grep _g77_
nm filename | grep _gfortran_
Two notes:
Grepping for ##GFORTRAN as geocar suggested is not reliable: it will only work on platforms where library-versioning is supported, which includes e.g. linux but not Windows or Mac OS.
It is still possible that some compiled code calls absolutely no support library function (if all it does is simple arithmetic and has not input-output, e.g.). In that case, unless it's compiled with debugging options, it's impossible to tell which compiler output it.
You might be able to figure it out by using nm, and seeing if the compiled code uses functions from one or the other, but that's quite a hack. You may be able to figure it out based on which library is available (if there's no libg2c available, then it wasn't g77, for example), but then you still have some ambiguity if both are available. If you can build the dependency yourself, then you can use have one part of your build process tell another part somehow (variable, file, etc.) which one you used.