In the ELF spec excerpted from the System V ABI, various functions are referenced as exec(BA_OS), as on page 7 of 1. Other functions are referenced with KE_OS. What do these *_OS symbols mean?
It turns out that page 11 of the latest base document describes "components of conforming systems", wherein "BA" means "base system", "KE" means "kernel extension" while "OS" means "operating system service routines" and "LIB" means "general library routines".
Related
I downloaded http://www.rebol.org/view-script.r?script=utf-8.r
when executing it, I get this error:
"map has no value".
I can't find rebol map libary anywhere.
That utf-8.r script has a dependency declared in his header:
Needs: [%hof.r]
You can find that script here. It contains the map function definition among many others.
I am trying to learn a thing or two about assembly language by studying the instructions in some shared objects. I have encountered a construction where a call instruction leads to 1 byte after its beginning, for example (output from hte):
af6fc | e8fcffffff call af6fdh
Clearly the destination address must be replaced by a proper function (which I know in this case is strcmp). I find this strange because in other parts of the same shared object the same strcmp function is called using the .got / .plt mechanism eliminating the need to rewrite parts of .text. In the latter case the destination function can be identified by studying the .rel.plt table along with .dynsym. But how do I find where the immediate address is redirected to in the former? I could not find any occurrence of the addresses af6fc or af6fd in any of the sections, at least not in those made accessible by hte.
You didn't say which platform you are on. It appears to be ix86.
On ix86, it is possible to link non--fPIC compiled code into a shared library (this produces a library with text relocations, which is suboptimal).
If you dump dynamic relocations with objdump -R foo.so, you should see that there is a relocation against address 0xaf6fd. The dynamic linker will update 4 bytes at 0xaf6fd to point to wherever the relocation tells it to after loading foo.so.
in other parts of the same shared object the same strcmp function is called using the .got / .plt mechanism
These calls come from objects that were (properly) compiled with -fPIC.
Hi everyone.
I have to work with old utility: which converts xls into txt.
There was a small problem in logic of the utility, but the problem is in other thing...
The utility consists of two parts: exe module and dll module, and uses MFC.
In exe project we have
pInit = (t_bXR_Init)GetProcAddress(hExcel, _T("bXR_Init"));
and
pInit("logfiles",false);
In dll project we have
typedef bool (*t_bXR_Init) (CString const &strlogfilespath, bool btxtfile);
XLSREADER_API bool bXR_Init(CString const &strlogfilespath, bool btxtfile);
The problem is when we send argument "logfiles" into the function it doesn't get it. It's strange, 'cause all other parameters are send properly.
The reason is somehow connected with using of CString. But I don't know how...
XLSREADER_API is defined as:
#define XLSREADER_API extern "C" __declspec(dllimport)
Also I've added
AFX_MANAGE_STATE(AfxGetStaticModuleState());
in the beginning of function's body (for bXR_Init). But it didn't help.
Also I tried to change some settings for these two projects, all settings are the same (e.g. calling conversion is __cldecl(/Gd); I build either debug versions exe and dll or release version of exe and dll simultaneously).
Also I tried to use CString instead of CString& - the same situation. It works properly if use char*, but boss says to find what the origin of the problem is at first.
What may lead to the problem (the function doesn't get CString parameter)?
To pass a complex type such as a CString across a DLL boundary you have to make sure that both the DLL and the exe are using the exact same DLL libraries. Set "Runtime Library" to multi-threaded DLL and set "Use of MFC" to Use MFC in a Shared DLL. Also, don't mix debug and release modules: Both must be the same.
Without these conditions you get two different heaps, and you can't keep the allocations/deletions compatible with two heaps.
Try passing an actual CString parameter to the call:
CString sPath = "logfiles";
pInit(sPath,false);
wtfigo! (what the f is going on)
the problem is solved.
I discovered, that exe project had "character set" = "use multibyte character set"
and dll project had "character set" = "use unicode character set".
So, dll function got CString with char* inside, but considered it as CString with wchat_t* inside. And it looked as garbage (as complete garbage on my pc and as chinese symbols on my workmate's pc).
I changed "character set" for exe project to "use unicode character set" and discovered about 60 errors.
Then I read an article http://habrahabr.ru/post/164193/ (in russian; or in english: http://www.codeproject.com/Articles/76252/What-are-TCHAR-WCHAR-LPSTR-LPWSTR-LPCTSTR-etc).
And fixed all errors, widely used macroses from TCHAR.h (MSDN helped me).
Thanks everybody for your help.
I have a program which makes use of boost_regex. The library boost_regex has an undefined symbol named differently with respect to the version of boost I am using. For instance, when I use boost version 1.49, libboost_regex.so contains an undefined symbol called u_tolower_49. This symbol can be found within libicuuc.so.
Obviously, if an user who doesn’t have icu compiles my program, the link stage will fail because that symbol is missing. So I decided to add it to configure.ac so that the configuration stage fails before starting the compilation.
configure.ac
...
AC_SEARCH_LIBS([u_tolower_49],[icuuc], , AC_MSG_ERROR([Unable to find icuuc, make sure ICU is installed.]))
...
Now my problem is that when the user’s version of boost is 48, the symbol is no longer named u_tolower_49 but u_tolower_48.
How can I tweak configure.ac to make sure that the configuration fails regardless of the version of boost the user has?
Nest the checks:
AC_SEARCH_LIBS([u_tolower_49],[icuuc],[],[
AC_SEARCH_LIBS([u_tolower_48],[icuuc],[],[
AC_MSG_ERROR([Unable to find icuuc, make sure ICU is installed.])
])
])
This is at least a documentation error, if not a bug.
In VB.NET prior to .NET 4.0 (i.e. VB.NET 7 through 9) an empty Structure declaration fails at compile-time with
error BC30281: Structure 'MySimpleEmpty' must contain at least one instance member variable or Event declaration.
E.g. The following two structures compile successfully in VB10, and not prior:
Structure MySimpleEmpty
End Structure
Public Structure AnotherEmpty
Public Const StillEmpty As Boolean = True
End Structure
I note the documentation for the Error BC30281 stops at VB9, but the documentation for the Structure statement still has the datamemberdeclarations as required even as of VB11 (.NET 4.5 VS2012).
These two Structures compile in VB11 (VS2012) as well. (Thanks John Woo.)
Is there some blog entry or documentation confirming this is an intended change or a bug in VB10 and later?
Microsoft have marked this as a fixed bug, without actually stating what was fixed.
The VB11 (VS2012) documentation now says the datamemberdeclarations are optional in the grammar, but in the Parts table it says "Required. Zero or more..."!
I guess that's a fix... The VB10 (VS2010) documentation hasn't been changed.