Jump to page: 1 2
Thread overview
Dwarf Exception Handling now on FreeBSD!
Jan 31, 2016
Walter Bright
Jan 31, 2016
ZombineDev
Feb 01, 2016
Charles
Feb 01, 2016
Walter Bright
Feb 01, 2016
Rikki Cattermole
Feb 01, 2016
Walter Bright
Feb 01, 2016
Rikki Cattermole
Feb 02, 2016
Charles
Feb 03, 2016
Jonathan M Davis
Feb 03, 2016
Brad Roberts
Feb 04, 2016
Jacob Carlborg
Feb 04, 2016
Brad Roberts
Feb 04, 2016
Jacob Carlborg
Feb 04, 2016
Joakim
Feb 06, 2016
Jonathan M Davis
Feb 06, 2016
Walter Bright
January 30, 2016
32/64 support now on Linux and FreeBSD.

  https://github.com/D-Programming-Language/dmd/pull/5376

Turns out that FreeBSD is close enough to Linux that it "just worked".

Recently, there was a long thread entitled "C++17" where people are asking for better C++ interoperability. Well, here's a ripe plum for anyone wanting valuable compiler street cred!

Make the Dwarf EH support work on OSX 32 and 64.

I bet that nearly all the work will be in changing the ELF fixups to MACH-O fixups in the gcc_except_table and eh_frame sections. Use an object dumper to see what g++ uses for fixups in those sections, and do the same.

As for me, I'll be implementing C++ multiple inheritance class layout, because Manu's problems have made it clear we have to do that.
January 31, 2016
On Sunday, 31 January 2016 at 06:34:26 UTC, Walter Bright wrote:
> 32/64 support now on Linux and FreeBSD.
>
>   https://github.com/D-Programming-Language/dmd/pull/5376
>
> Turns out that FreeBSD is close enough to Linux that it "just worked".
>
> Recently, there was a long thread entitled "C++17" where people are asking for better C++ interoperability. Well, here's a ripe plum for anyone wanting valuable compiler street cred!
>
> Make the Dwarf EH support work on OSX 32 and 64.
>
> I bet that nearly all the work will be in changing the ELF fixups to MACH-O fixups in the gcc_except_table and eh_frame sections. Use an object dumper to see what g++ uses for fixups in those sections, and do the same.
>
> As for me, I'll be implementing C++ multiple inheritance class layout, because Manu's problems have made it clear we have to do that.

Nice work!

I suggest that after that you look into RAII C++ interop (calling C++ destructors at the end of the scope), because it is critical for interfacing with modern C++ projects that make heavy use of it.

Adding dummy methods as the first members of an interface to satisfy the vtbl layout is quite error-prone and useless when you need to make the cleanup from the D side!
February 01, 2016
On Sunday, 31 January 2016 at 06:34:26 UTC, Walter Bright wrote:
> Well, here's a ripe plum for anyone wanting valuable compiler street cred!
>
> Make the Dwarf EH support work on OSX 32 and 64.


Are there any future plans for Win64 since it won't ever support dwarf exceptions from how I understand it? Or does it, and I'm strongly mistaken?
January 31, 2016
On 1/31/2016 6:32 PM, Charles wrote:
> Are there any future plans for Win64 since it won't ever support dwarf
> exceptions from how I understand it? Or does it, and I'm strongly mistaken?

VC++'s Win64 exception handling scheme is not at all the Win32 scheme and definitely not Dwarf EH. Supporting it would be an additional level of effort on par with supporting Dwarf EH, presuming documentation on it can be found. (I haven't looked for it.)

If someone wants to search for a spec for it, that would be a good start.
February 01, 2016
On 01/02/16 4:01 PM, Walter Bright wrote:
> On 1/31/2016 6:32 PM, Charles wrote:
>> Are there any future plans for Win64 since it won't ever support dwarf
>> exceptions from how I understand it? Or does it, and I'm strongly
>> mistaken?
>
> VC++'s Win64 exception handling scheme is not at all the Win32 scheme
> and definitely not Dwarf EH. Supporting it would be an additional level
> of effort on par with supporting Dwarf EH, presuming documentation on it
> can be found. (I haven't looked for it.)
>
> If someone wants to search for a spec for it, that would be a good start.

I believe the last link will be most helpful. But first will give you a good understanding and where to go(its for the linker).

If anybody wishes to look more into it.

https://msdn.microsoft.com/en-us/library/1deeycx5.aspx
https://msdn.microsoft.com/en-us/library/swezty51.aspx
https://msdn.microsoft.com/en-us/library/1eyas8tf.aspx
January 31, 2016
On 1/31/2016 7:04 PM, Rikki Cattermole wrote:
> On 01/02/16 4:01 PM, Walter Bright wrote:
>> On 1/31/2016 6:32 PM, Charles wrote:
>>> Are there any future plans for Win64 since it won't ever support dwarf
>>> exceptions from how I understand it? Or does it, and I'm strongly
>>> mistaken?
>>
>> VC++'s Win64 exception handling scheme is not at all the Win32 scheme
>> and definitely not Dwarf EH. Supporting it would be an additional level
>> of effort on par with supporting Dwarf EH, presuming documentation on it
>> can be found. (I haven't looked for it.)
>>
>> If someone wants to search for a spec for it, that would be a good start.
>
> I believe the last link will be most helpful. But first will give you a good
> understanding and where to go(its for the linker).
>
> If anybody wishes to look more into it.
>
> https://msdn.microsoft.com/en-us/library/1deeycx5.aspx
> https://msdn.microsoft.com/en-us/library/swezty51.aspx
> https://msdn.microsoft.com/en-us/library/1eyas8tf.aspx

They have bits and pieces of the info, but nothing about what is actually generated to, say, catch an exception.
February 01, 2016
On 01/02/16 4:23 PM, Walter Bright wrote:
> On 1/31/2016 7:04 PM, Rikki Cattermole wrote:
>> On 01/02/16 4:01 PM, Walter Bright wrote:
>>> On 1/31/2016 6:32 PM, Charles wrote:
>>>> Are there any future plans for Win64 since it won't ever support dwarf
>>>> exceptions from how I understand it? Or does it, and I'm strongly
>>>> mistaken?
>>>
>>> VC++'s Win64 exception handling scheme is not at all the Win32 scheme
>>> and definitely not Dwarf EH. Supporting it would be an additional level
>>> of effort on par with supporting Dwarf EH, presuming documentation on it
>>> can be found. (I haven't looked for it.)
>>>
>>> If someone wants to search for a spec for it, that would be a good
>>> start.
>>
>> I believe the last link will be most helpful. But first will give you
>> a good
>> understanding and where to go(its for the linker).
>>
>> If anybody wishes to look more into it.
>>
>> https://msdn.microsoft.com/en-us/library/1deeycx5.aspx
>> https://msdn.microsoft.com/en-us/library/swezty51.aspx
>> https://msdn.microsoft.com/en-us/library/1eyas8tf.aspx
>
> They have bits and pieces of the info, but nothing about what is
> actually generated to, say, catch an exception.

Hmm you're right.
But on the plus side I found this:
http://www.programmingunlimited.net/siteexec/content.cgi?page=libseh

It even supports Digital Mars C/C++ compiler!
February 02, 2016
On Monday, 1 February 2016 at 03:23:18 UTC, Walter Bright wrote:
>
> They have bits and pieces of the info, but nothing about what is actually generated to, say, catch an exception.

Gotcha, is this something you'd expect to be easily obtainable (e.g. ask Microsoft Rep saying we want to make it easier for people to use their product?), or is this something that would probably require some sort of reverse engineering effort?
February 03, 2016
On Sunday, 31 January 2016 at 06:34:26 UTC, Walter Bright wrote:
> 32/64 support now on Linux and FreeBSD.
>
>   https://github.com/D-Programming-Language/dmd/pull/5376
>
> Turns out that FreeBSD is close enough to Linux that it "just worked".

It's always nice when that happens, especially when there's not much FreeBSD-specific work going on, and the autotesters have generally been on older versions of FreeBSD such that issues on the newer versions don't always get noticed (e.g. for a while there, the shared library stuff passed the tests on FreeBSD 8 but not later; fortunately Martin got that fixed though).

- Jonathan M Davis
February 03, 2016
On 2/3/16 11:28 AM, Jonathan M Davis via Digitalmars-d wrote:
> On Sunday, 31 January 2016 at 06:34:26 UTC, Walter Bright wrote:
>> 32/64 support now on Linux and FreeBSD.
>>
>>   https://github.com/D-Programming-Language/dmd/pull/5376
>>
>> Turns out that FreeBSD is close enough to Linux that it "just worked".
>
> It's always nice when that happens, especially when there's not much FreeBSD-specific work going on,
> and the autotesters have generally been on older versions of FreeBSD such that issues on the newer
> versions don't always get noticed (e.g. for a while there, the shared library stuff passed the tests
> on FreeBSD 8 but not later; fortunately Martin got that fixed though).
>
> - Jonathan M Davis

I haven't put much time into investigation, but the last time I tried it, neither 9 nor 10 passed the test suite.  If someone puts in the effort to get either or both of those working, I'd be happy to upgrade some of the freebsd testers to newer versions.  There's currently 4 freebsd machines, so plenty of room to have a mix of versions.  Not enough to test every combination of version and bitness, but enough to allow randomness to expose issues.
« First   ‹ Prev
1 2