PDCLib: Platform configs required

[Solar]

In the past, I have recieved several offers to help with PDCLib. I have always turned them down so far. Now there are two rather specific things that would indeed help me getting forward towards a v0.5 release.

The current working branch is located at https://negix.net/svn/pdclib/branches/stdio_rewrite - and with "make links", "make all", "make tests", and "make regtests" you'll get a completely clean run - no compiler warnings, no unexpected errors from the testdrivers.

That is, on a 32-bit Linux.

On a 64-bit Linux, you'll get warnings and errors resulting from different type widths - e.g., long being 8 byte instead of 4 byte as stated in _PDCLIB_config.h.

I would be much obliged if someone would go through the sources and fix those problems, so I could provide a 64-bit Linux example config in addition to the existing 32-bit one. I could do it myself, but given the very little time I find to work on PDCLib these days I'd really welcome the help here.

Access to the repository is read-only; you can provide fixes, hints, or patches in any way you like; diff output sent to solar (at) rootdirectory dot de would be preferred.

Thank you!

[01000101]

I can probably help you out with this as I'm going through my own personal libraries and creating the rift between 32 and 64 bit types just for standardization and such. I'll take a look at it tomorrow when I have more time (it is quite late here ATM).

[Solar]

If someone is bored, a config for Cygwin would also be welcome. I've been doing some work recently on other machines than my own laptop, and found that the "example" platform config isn't as portable as I thought it to be.

[quok]

Solar, out of curiousity, what version of GCC were you using? I just attempted compiling with GCC 4.3.1 (32-bit) and got a few warnings, but they're easily fixed.

[Solar]

The latest stable on Ubuntu is v4.2.4, on Gentoo it's 4.1.2. Since I don't use packages not marked stable unless absolutely necessary, that's what I'm using ATM.

[quok]

The latest stable on Ubuntu is v4.2.4, on Gentoo it's 4.1.2. Since I don't use packages not marked stable unless absolutely necessary, that's what I'm using ATM.

Ah, that explains why I get warnings with GCC 4.3.1, which is what OpenSUSE 11.0 uses, and what is on my Debian Testing box.

[Solar]

Reviving this from the graveyard of time...

By now, there is a 64bit _PDCLIB_config.h available. Unpacking the current branch, calling "make links", copying ./platform/example_64/internals/_PDCLIB_config.h to ./internals, and calling "make pdclib.a" compiles cleanly.

The problem is, the stdarg macros defined in _PDCLIB_config.h, which work just fine on x86, fail dismally on x86_64. Actually, the test driver for them hangs. (And the test driver for malloc(), which relies on stdarg.h, reports false negatives.)

I want to focus on other things for now (like, getting v0.5 done this year), so I would very much welcome it if somebody could check this out, and submit a x86_64 stdarg implementation under Public Domain terms.

Any takers?

PS: Of course I could simply use the GCC builtins. The v1.0 release of the Library will contain appropriate configs for popular compilers, making use of builtins where possible. But the idea behind the "example" platforms is to provide a generic solution that works on as many platforms / compilers as possible.

[Combuster]

The problem here is the register calling convention. I don't know how to create a load of macros that determine which register to start, when to switch to the stack, and then I'm not even talking about creating compiler-independent assembly to read register X and sort out the different calling conventions per platform... (see Wikipedia for the details)

Bottom line: I don't believe that you can make a portable stdargs for any register-calling-convention machine.

[Solar]

The problem here is the register calling convention...

Yikes! I didn't know that, as I've never toyed with the x86_64 architecture so far.

OK, that's a dead case then. I'll just add the compiler builtins to the config.

Thanks for the info!

[ru2aqare]

The problem here is the register calling convention. I don't know how to create a load of macros that determine which register to start, when to switch to the stack, and then I'm not even talking about creating compiler-independent assembly to read register X and sort out the different calling conventions per platform... (see Wikipedia for the details)

I believe most x64 compilers will store arguments back to the stack if they detect that it's address is taken (well at least msvc does this). So I don't think register calling conventions would be that much of an obstacle.

[whowhatwhere]

The problem here is the register calling convention. I don't know how to create a load of macros that determine which register to start, when to switch to the stack, and then I'm not even talking about creating compiler-independent assembly to read register X and sort out the different calling conventions per platform... (see Wikipedia for the details)

I believe most x64 compilers will store arguments back to the stack if they detect that it's address is taken (well at least msvc does this). So I don't think register calling conventions would be that much of an obstacle.

The calling convention is described quite accurately in the SVR.4 docs.

SVR4/i386 (Original SCO Document): http://www.sco.com/developers/devspecs/abi386-4.pdf
SVR4/i386 (x86-64 supplement): http://www.x86-64.org/documentation/abi.pdf

[JamesM]

The problem here is the register calling convention. I don't know how to create a load of macros that determine which register to start, when to switch to the stack, and then I'm not even talking about creating compiler-independent assembly to read register X and sort out the different calling conventions per platform... (see Wikipedia for the details)

I believe most x64 compilers will store arguments back to the stack if they detect that it's address is taken (well at least msvc does this). So I don't think register calling conventions would be that much of an obstacle.

Correct, the x86-64 calling convention requires a stack address for every argument given, as a spill location. So you could possibly do:

Code: Select all

asm volatile("" : : : "rdi,rsi,rdx,rcx");

To force them to be spilled back to memory. GCC shouldn't create another temporary for them as the shadow space is available...

YMMV, I'd objdump it first!

[Combuster]

The windows calling convention indeed specifies register spilling space. However, the System V ABI document listed has different semantics, and doesn't define any spilling area. Both of which agrees with Wikipedia, which I already referenced above.

Still, the need for a platform-specific method of either grabbing the registers, or forcing them onto the stack will not help PDClib...

[Solar]

Well, if the generic implementation doesn't cover x86_64, that's not a problem really. I develop on a 32bit system, and the example platform is primarily for allowing me to actually compile and test the stuff. In the end, the respective platform/toolchain implementations will get their own configs anyway, and until then I'll simply cheat and use the GCC builtins when working on a 64bit platform.

Oh, and by the way... v0.5 is bound to be released soon.

Yes, really, this time.

[Combuster]

Oh, and by the way... v0.5 is bound to be released soon.

Yes, really, this time.

/me realises the distance factor messing up the "buying a beer" idea....