I see an Elf file may contains version sections like .gnu.version (readelf -V to display thire contents). What is the meaning of these information? Is there any documentation about version sections?
I'm afraid the most complete piece of documentation is Ulrich Drepper's notes however stale/incomplete they are. You can also get some inspiration from Solaris docs (Linux dynamic linking is a shameles^W copy of Solaris after all).
Many people have complained about lack of definitive documentation including Glibc maintainers themselves.
In addition to yugr's more implementation documentation, I have blogged about this a few times in the past, so you can look there for some "why and how to use" information.
Related
The title tells it all:
Does breezy fully replace bzr, at least in msys2?
E.g., by aliasing.
I found little info on this:
https://github.com/NixOS/nixpkgs/issues/80740
Yes, Breezy is a full replacement for Bazaar. It's derived from the Bazaar codebase, and compatible with the Bazaar command-line interface.
There are a large number of changes to the internal API, but unless you use third-party plugins or use scripts that use the bzrlib API, that should not be relevant to you.
We've also dropped support for a number of older platforms (e.g. Windows '95 and '98). I don't think msys2 was ever explicitly supported as a platform, but we're happy to help fix any issues you may run into. See https://www.breezy-vcs.org/pages/support.html for ways to reach out to us.
You can read more about the rationale for the fork here:
https://lists.ubuntu.com/archives/bazaar/2017q2/076170.html
https://www.jelmer.uk/breezy-intro.html
I need to write a CMake FindXYZ-type module. Googling, I've found this guide:
https://cmake.org/Wiki/CMake:How_To_Find_Libraries
from Kitware, but there's a disclaimer about it being deprecated. Which significant changes, if any, have been made to how these modules are written over the past, say, 6-7 years?
Yes, the CMake Wiki's content now officially moved inside CMake's documentation, so the "deprecated" warning is more a general one that the Wiki is no longer looked after.
In your case the main part of CMake Wiki: How To Find Libraries moved to CMake's documentation cmake-packages chapter.
What has changed?
I think the major change over the last years is what Stephen Kelly in his "Embracing Modern CMake" talk called:
Modern CMake packages define IMPORTED targets
find_package(Foo REQUIRED)
add_executable(hello main.cpp)
target_link_libraries(hello
Foo::Core
)
The same basic tint is found in CMake's documentation cmake-developer - Find Modules chapter:
The traditional approach is to use variables for everything, including libraries and executables. This is what most of the existing find modules provided by CMake do.
The more modern approach is to behave as much like config file packages files as possible, by providing imported target. This has the advantage of propagating Transitive Usage Requirements to consumers.
Details
You can see this "modern approach" as an extension of the previous methods (like in "FindZLIB: Add imported target and documentation" commit).
What should definitely be there (the core of all "Find Modules" for years now) is the find_package_handle_standard_args() macro.
This macro is build around the ..._FOUND cached variable handling.
My recommendation would be to concentrate on the imported targets and the ..._INCLUDE_DIRS and ..._LIBRARIES variables are just a side effect of having to cache your find results somewhere.
No, I don't think there's any significant changes. I still use it.
I think they are just trying to get you to look at their other documentation, like find_package.
In writing new Find modules, I normally just look at the other
FindXXX.cmake
as examples/templates and go from there.
Is it possible to extract a binary, to get the code that is behind the binary? With Class-dump you can see the implementation addresses, but is it possible to also see the code thats IN the implementation addresses? Is there ANY way to do it?
All your code compiles to single instructions, placed in the text section of your executable. The compiler is responsible for translating your higher level language to the processor specific instructions, which are simpler. Reverting this process would be nearly impossible, unless the code is quite simple. Some problems are ambiguity of statements, and the overall readability: local variables, for instance, will be nothing but an offset address.
If you want to read the disassembled code (the instructions of which the higher level code was compiled to) use this command in an executable:
otool -tV file
You can decompile (more accurately, disassemble) a binary and get it's assembly, but there is no way to get back the original Objective-C.
My curiosity begs me to ask why you want to do this!?
otx http://otx.osxninja.com/ is a good tool for symbolicating the otool based disassembly
It will handle both x86_64 and i386 disassembly.
and
Mach-O-Scope https://github.com/smorr/Mach-O-Scope is a a tool built on top of otx to dump it all into a sqlite3 database for browsing and annotating.
It won't give you the original source -- but it will get you pretty close providing you with the messages that are being sent around in methods.
In the Portable Executable format, there is a directory named IMAGE_DIRECTORY_ENTRY_LOAD_CONFIG. Can someone provide a URL with a good explanation of this directory and its real usage? Why do some apps use this feature?
It seems originally it was used for some rarely-used features (e.g. LockPrefixTable, I've only seen it in kernel32.dll). These days you generally only see it used for the /safeseh feature (SEHandlerTable/SEHandlerCount).
In the past I've used Doxygen for C and C++, but now I've been thrown on Fortran project and I would like to get a quick all encompassing look at the architecture.
In the past I've found reverse engineering tools to be useful where no documentation of the architecture exists.
So, is there a tool out there that will reverse engineer Fortran code?
I tried to use Doxygen, but didn't have any luck. I will be working with two different projects - one Fortran 90 and I think is in Fortran 77.
Thanks for any insights and feedback.
Tools which may help with reverse engineering:
SciTools Understand
Link with some more tools (search "fortran")
Also, maybe some of these unit testing frameworks will be helpful (I haven't used them, so I cannot comment on the pros and cons of any of them):
FUnit
FRUIT
Ftnunit
(these links link to fortranwiki, where you can find a tidbit on every one of them, and from there there are links to their home sites).
Doxygen 1.6.1 will generate documentation, call graphs, etc. for Fortran source code in free-format (F90) format. You are out of luck for auto-documenting fixed-format (F77) code with doxygen.
All is not lost, however. The conversion from fixed to free format is straightforward and can be automated to a great degree - change comment characters to '!', change continuation characters to '&', and append '&' to lines to be continued. In fact, if the appended continuation character is placed in column 73, it should be ignored by standard F77 compilers (which still only recognize code in columns 1 through 72) but will be recognized by F9x/F2003/F2008 compilers. This allows the same code to be recognized as both in fixed and free format, which lets you gracefully migrate from one format to the other.
Conveniently, there are about a thousand small programs that will do this format adjustment to some degree or another. Realistically, if you're going to be maintaining the code, you might as well move it away from the 1928 spec for Hollerith (IBM) punched cards. :)