D seems interesting, but...

[Iain Buclaw]

On 15 October 2012 23:21, Gerry Weaver <gerryw at compvia.com> wrote:
> On Monday, 15 October 2012 at 20:45:39 UTC, Gerry Weaver wrote:
>>
>> On Monday, 15 October 2012 at 20:19:22 UTC, Gerry Weaver wrote:
>>>
>>> On Monday, 15 October 2012 at 19:38:24 UTC, H. S. Teoh wrote:
>>>>
>>>> On Mon, Oct 15, 2012 at 08:46:21PM +0200, Gerry Weaver wrote:
>>>> [...]
>>>>>
>>>>> It just occurred to me that I've seen this type of file issue
>>>>> before. If memory serves, it was related to the attempt to load a
>>>>> 64bit lib on a 32bit system. It was an odd problem, because it
>>>>> didn't fail in the way one would expect. The process in that case
>>>>> was reading garbage from memory. I don't get how it could be reading
>>>>> nothing though. Anyway, I'm going to look into this possibility. I
>>>>> found some notes that I made during that time and it does have a
>>>>> similar feel to it. I'll let y'all know what I find.
>>>>
>>>> [...]
>>>>
>>>> Now, that does sound like it could be the source of the problem. If dmd
>>>> was reading garbage from the file, if there just happens to be, say, a
>>>> binary 0 at the beginning (or whatever it is that causes dmd to think it
>>>> has reached EOF), then it would just stop and produce an empty object
>>>> file. So the linker will fail to find the symbols that dmd emits when it
>>>> encounters main().
>>>>
>>>>
>>>> T
>>>
>>>
>>> Hi,
>>>
>>> When running dmd, none of the read (and friends) syscalls happen as far
>>> as the kernel is concerned. This would lend some credibility to the lib
>>> theory. However, it's quite odd that results are the same for each time dmd
>>> is executed. I would expect a random result or even a segfault/abort on
>>> different runs.
>>>
>>> Thanks,
>>> -G
>>
>>
>> Hi,
>>
>> I think I have satisfied myself that this is probably a fluke. We have
>> captured enough in this thread that there will be a good starting point
>> should the issue ever come up again. It may sound odd, but I'm actually glad
>> it happened. It helped me realize an issue with a system that would probably
>> have manifested itself in some other frustrating and embarrassing way later
>> on ;-)
>>
>> Thanks everyone,
>> -G
>
>
> Hi,
>
> Sorry, I neglected to mention something. I did a test with a zero length
> file and compared the output to the problem case. The output was, in fact,
> identical. Would it be difficult to do a simple test for zero length files
> and output a message like "error: zero length/empty file <filename>"? The
> output in this case is fairly misleading.
>
> Thanks,
> -G
>

It would be less misleading if we got rid of _tlsstart and _tlsend.
This would slim the error message down to...

---
/usr/lib/i386-linux-gnu/libphobos2.a(dmain2_459_1a5.o): In function
`_D2rt6dmain24mainUiPPaZi7runMainMFZv':
src/rt/dmain2.d:(.text._D2rt6dmain24mainUiPPaZi7runMainMFZv+0x10):
undefined reference to `_Dmain'
---

Which is less cryptic, and everyone can spot a "undefined reference to
`_Dmain'" more easily.

However _tls is engraved in the current design of TLS.  On the move to
shared libraries, I would hope that these be removed and replaced.


Regards
-- 
Iain Buclaw

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