On 29 September 2013 17:28, Jacob Carlborg <doob@me.com> wrote:
> On 2013-09-29 12:25, Iain Buclaw wrote:
>
>> - Though I can't be sure because I don't know what it is actually doing other than creating some custom bracketed segment (Really??? Is this truly necessary? That's about as useful as having a separate calling convention just for one language.  Oh wait!!!)  However, see point one on why there is uncertainty surrounding this.
>
>
> How is exception handling tables, module infos, GC range and TLS data handled now in GDC?
>

1. GDC uses libunwind for EH.
2. ModuleInfos  are put into a linked list - this is for all platforms
(which differs from dmd's runtime at last check).  There's a .ctor
function emitted into the module which attaches itself to
_Dmodule_ref.
3. I assume when you say GC range, you mean __data_start / _end?
4. TLS data depends on the platform.  Linux has a .tdata and .tbss
section that is not bracketed for example...


Regards
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On 29/09/13 12:25, Iain Buclaw wrote:
> Not following dmd's way of doing things is nothing new however...

I don't understand why the solution wasn't (or couldn't be) designed from the start to work with all three D compilers.  Can anyone offer an explanation?

On 2013-09-29 19:57, Joseph Rushton Wakeling wrote:

> I don't understand why the solution wasn't (or couldn't be) designed
> from the start to work with all three D compilers.  Can anyone offer an
> explanation?

I think Walter picked an easy solution that he know would work. I don't think he knew about platform specific functions such as "getsectbynamefromheader" and "dl_iterate_phdr".

-- 
/Jacob Carlborg

On 29 September 2013 20:12, Jacob Carlborg <doob@me.com> wrote:
> On 2013-09-29 19:57, Joseph Rushton Wakeling wrote:
>
>> I don't understand why the solution wasn't (or couldn't be) designed from the start to work with all three D compilers.  Can anyone offer an explanation?
>
>
> I think Walter picked an easy solution that he know would work. I don't think he knew about platform specific functions such as "getsectbynamefromheader" and "dl_iterate_phdr".
>

I've spoken to Walter about this before, he was quite open about taking a "make it work, then try to make it pretty" approach to things.  My biggest pet peeve is probably how dmd treats va_arg a totally inconsistent way across each platform dmd supports.  In comparison gdc handles va_arg in one way, and it is identical across each platform supported (and platforms that have not yet gotten support ;)


Regards
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On 29 September 2013 18:57, Joseph Rushton Wakeling <joseph.wakeling@webdrake.net> wrote:
> On 29/09/13 12:25, Iain Buclaw wrote:
>>
>> Not following dmd's way of doing things is nothing new however...
>
>
> I don't understand why the solution wasn't (or couldn't be) designed from the start to work with all three D compilers.  Can anyone offer an explanation?
>

Many bad things get implemented in dmd without discussion.

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On Sunday, 29 September 2013 at 19:24:40 UTC, Iain Buclaw wrote:
> My biggest pet peeve is probably how dmd treats va_arg a
> totally inconsistent way across each platform dmd supports.  In
> comparison gdc handles va_arg in one way, and it is identical across
> each platform supported (and platforms that have not yet gotten
> support ;)

… with the most irritating aspect being that DMD doesn't correctly implement va_copy on x86_64 (at least it didn't last time I checked), yet nobody seems to have noticed so far.

This was in fact the reason for me to put fixing the related state of affairs in LDC on the back burner, although I'd highly appreciate if somebody with DMD backend experience would aid in getting this done and over with once and for all.

David

On 2013-09-30 00:07, David Nadlinger wrote:

> … with the most irritating aspect being that DMD doesn't correctly
> implement va_copy on x86_64 (at least it didn't last time I checked),
> yet nobody seems to have noticed so far.

Perhaps it only matter when interfacing with C. Perhaps not that many people actually use varargs at all. I guess most people use variadic templates. They're easier to deal with.

-- 
/Jacob Carlborg

On Sep 30, 2013 7:30 AM, "Jacob Carlborg" <doob@me.com> wrote:
>
> On 2013-09-30 00:07, David Nadlinger wrote:
>
>> … with the most irritating aspect being that DMD doesn't correctly implement va_copy on x86_64 (at least it didn't last time I checked), yet nobody seems to have noticed so far.
>
>
> Perhaps it only matter when interfacing with C. Perhaps not that many
people actually use varargs at all. I guess most people use variadic templates. They're easier to deal with.
>

And they are @safe.  :)

Regards
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';