solaris port

Marcus R. Brown mrbrown at budcat.com
Mon May 1 08:08:20 PDT 2006


I ran into this problem (in a different form) on a 64-bit PPC-based 
platform.  Since dynamic arrays are technically C structs, you should 
observe whatever the C vararg ABI conventions are for that platform.  What 
ended up being particularly nasty for me where all the cases where Phobos 
tries to access vararg parms using direct stack pointers, which breaks on a 
64-bit platform where stack slots are padded and aligned to 64-bit 
boundaries.

Dynamic arrays in GDC are already passed as structs though, so I guess I 
would question why on Solaris they are passed as a pointer?

Brad Roberts <braddr at puremagic.com> wrote:
> I've been working on getting gdc working on solaris and have hit an
> interesting issue concerning a difference between the x86 and sparc abi's.
> The dynamic array struct looks like:
>
> struct dynamic_array
> {
>    int length;
>    void *ptr;
> }
>
> (work with me, that's approximate)
>
> On x86, when a da is passed to a function, both words of the structure are
> pushed and can be pulled off as individual words.  This is particularly
> useful with printf, as in this form:
>
>    printf("%.*s\n", dynamicString);
>
> That's 100% the same as, on x86:
>
>    printf("%.*s\n", dynamicString.length, dynamicString.ptr);
>
> On solaris, an indirect reference it passed as a single argument, so the
> first form of printf fails, though of course the second form works as
> expected.
>
> While printf isn't part of D, it's a rather common idiom that's offered
> and used by many.
>
> An 'obvious' thing to do would be to teach gdc to split dynamic arrays up
> and manually treat as two args to variadic functions.  I don't like that
> as a general solution.  Maybe do that for just extern (C)'ed functions,
> but even that I don't thing is a good idea.  I could be talked into it for
> just the printf family of functions, but that's a pretty disgusting hack.
>
> Anyone have any suggestions / thoughts for other ways to handle this?
>
> Later,
> Brad 





More information about the D.gnu mailing list