Question/suggestion about x32 libraries

[nrusl...@gmail.com]

I think, x32 is great not just for embedded applications but for desktops as well since most applications do not use > 4Gb. One thing I do not like is that it will require a separate set of system libraries which may defeat its original purpose of reducing cache and memory pressure.

An alternative is to use 64-bit mode system libraries and 32-bit applications (with specialized 32-bit libraries when really necessary) and specify during application initialization that mmap/brk is restricted to 4Gb. However, the problem would be a compatibility issues with void *, size_t, long, etc when interacting with 64-bit system library interface. Adding a special attribute to each type (like mode(DI)) in gcc can probably solve the problem but is too cumbersome for programmers since library code will need to be modified extensively which is unrealistic. But modifying definition in the beginning of headers seems to be more reasonable (especially if libraries already have macros like __BEGIN_DECLS or it can be added if necessary).

Correct me if I am wrong but would it be possible to add some compiler extension which would do something like this:

#pragma push(ABI)
#pragma ABI(LP64)

#include <header1.h>
#include <header2.h>

...

// library interface definitions
// all types that are typedefs of void* (pointers), long, size_t, etc are also changed LP64 in this region

#pragma pop(ABI)

// types and corresponding typedefs are restores to ILP32 standard

Clearly, LP64 can be replaced with something more general to preserve source compatibility with an ordinary 32 bit versions

Would be great to hear some feedback and shortcomings of these approach. Perhaps, it would be necessary to modify compiler extensively since it would normally assume fixed size type during all compilation period but should cause less problems with other existing code.

Ruslan

[Mike Frysinger]

why don't you just run x32 only? it's easy to do a native x32 build (and Gentoo already is doing releases like that).

there might be some closed source binaries in the 64bit world to deal with, but that is rarely the problem with embedded systems.
-mike

--
You received this message because you are subscribed to the Google Groups "X32 System V Application Binary Interface" group.
To unsubscribe from this group and stop receiving emails from it, send an email to x32-abi+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[nrusl...@gmail.com]

Just to clarify a little bit: I understand that certain things will break and I am not proposing to replace all 32 bit mode libraries. For instance void func(size_t *ptr) will certainly break. However, it is not uncommon for libraries to define their own type or use fixed-size types. At least, libc would certainly contain a great deal of functions that should not be affected (may be apart from strstr(), strchr() which can be handled separately).

[nrusl...@gmail.com]

Sorry for confusion, strchr(), strstr() are not affected but strtoul() is. (But it easy to work around using an inline wrapper or specialized version of the function for 32 bit.)

[nrusl...@gmail.com]

2 Mike:

It is possible to run x32 only, however, there is no guarantee that some application (e.g., database server, graphics/multimedia, etc) will not need more than 4Gb (especially if you consider mid-term or long-term perspective). So, occasionally you will end up loading two versions of libc, libpthread, qt, X11 libraries, etc which is probably not worth it. However, if you have 64 bit versions of these libraries, you may still run 32 bit address mode applications if they are capable of interacting with 64 bit address mode libraries (it is not very trivial but may be possible to do for commonly used libraries such as libc, libpthread).

Ruslan