Fix issue 120

[jpf91]

This pull request includes these changes to fix issue #120:

• The static array initializer fix posted in the bug report (Pad static arrays with single elements )
• The TypeInfoDeclaration::toSymbol code did not correctly set DECL_SIZE
• The size of ModuleInfo and ClassInfo is not known until the initializer is constructed. Added a helper method which generates a struct node with unknown size. Then infer the size in outdata and set it correctly.
• TypeInfoStruct::toDt produced variable length output. Fixed by using an extra static symbol for name. (This should also be fixed in upstream dmd and is also contained in this pull request: Verify TypeInfo sizes dlang/dmd#1128)
• The TypeInfo_Function and TypeInfo_Delegate declarations in druntime are wrong. The fix is already applied in upstream druntime (Fix TypeInfo_Function size in object.di dlang/druntime#307), but I included it here, so we don't have to wait for version 2.061.
• That dmd pull request will also error out if a TypeInfo declaration in druntime doesn't match the one in the compiler. So issues like that shouldn't happen again.
• Added code to outdata which detects size mismatches between initializer size, type size and declaration size and ices on these errors. (We sometimes have smaller initializers than DECL_SIZE, but I guess that's not a problem. So the code only checks for bigger initializers). This should make it easier to detect bugs which lead to problems with section anchors.

I tested those changes on x86, x64-64 and arm. There are no regressions in the test suite (which is especially important since this code introduces a new ice). Those changes produce the same testsuite output on ARM as using -fno-section-anchors (Actually, they're even a little better. Seems like I didn't correctly pass the -fno-section-anchors to the testsuite runner). So I hope these changes should fix all section anchor issues.

The testsuite results for reference: http://dl.dropbox.com/u/24218791/fix120/testsuite.html
(You might wonder why there is one more 'unresolved' runnable test with the new code on ARM: This is the runnable/test23.d test. It went from FAIL to UNRESOLVED. It now shows the same error on ARM as on X86)

Note: With this solution we don't have debug info for ClassInfos and ModuleInfos. This should really be fixed in the frontend, but that's more complicated than I thought. I'll file a bug report on the dmd bugtracker though, to make sure it won't be forgotten.

[ibuclaw]

layout_decl (csym->Stree); should do just fine.

[jpf91]

OK, updated. layout_decl needs a second parameter:

Second argument is the boundary that this field can be assumed to
be starting at (in bits).  Zero means it can be assumed aligned
on any boundary that may be needed. 

Is 0 ok in this case?

and the printf %wd complains on 32bit:

../../gcc-4.8-20120826/gcc/d/d-objfile.cc:971:94: warning: format '%wd' expects argument of type 'long long int', but argument 4 has type 'size_t {aka unsigned int}' [-Wformat]

is this ok or should we use some different format specifier?

[jpf91]

OK, implemented you suggestions. There are no regressions on x86, so as the check should turn those errors into ices I just assume it works on ARM (recompiling gdc and running the testsuite takes more than 10 hours).

The relayout_decl and similar functions are not really documented, right? I didn't know these functions existed at all. I also searched for something like internal_error but couldn't find it ;-)

BTW: Does GDC not use HOST_WIDE_INT at all? I thought that's needed when using a 32bit->64bit cross compiler (but probably sizes > uint.max won't happen anyway).

[ibuclaw]

1. Yep, use 0 in layout_decl.
2. %wd is the formatter for HOST_WIDE_INT types (GCC has it's own formatting parser with use of it's warning and error routines (see diagnostic.c / *-pretty-print.c) - I assume you were getting that because I put down size_t.
3. No, that wasn't intentional - I just misread the patch when I was quickly typing minor corrections away. To be honest, I didn't test anything I wrote - I just wrote it think "this works in my head". :-)
4. I'm pretty certain GCC documentation consists of only the MACROS that frontends / targets can use. For everything else, either look how other frontends work, or look at the headers.
5. GDC uses dinteger_t when handling const values - which should be typed as the same size.

[jpf91]

OK, it's using HOST_WIDE_INT and %wd now. Is there anything more that needs to be done for this pull request?

[ibuclaw]

On 24 September 2012 11:46, Johannes Pfau notifications@github.com wrote:

OK, it's using HOST_WIDE_INT and %wd now. Is there anything more that
needs to be done for this pull request?

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/30#issuecomment-8813589.

I'll just check it locally my side. I think I spot one or two
coding-convention fixes that I'll do later...

Iain Buclaw

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

[jpf91]

OK, thanks.

[ibuclaw]

Not sure if it's problems with my set-up, or the fact that I'm using qemu emulation to test, but compiling with this patch causes segv in gc_malloc.

Will try without to see what happens.

[jpf91]

On ARM only or on x86? I guess this means even a simple hello world segfaults? Sounds exectly like the first symptom related to -fsection-anchors we had found and should be fixed by the static array padding commit.

If you try it on ARM without this test, please also try compilling druntime with -fno-section-anchors, as this really sounds like the same old problem.

But it's weird, I've run hello worlds and more advanced applications (dustmite) with those changes and everything worked fine.

[ibuclaw]

On 2 October 2012 13:59, Johannes Pfau notifications@github.com wrote:

On ARM only or on x86? I guess this means even a simple hello world
segfaults? Sounds exectly like the first symptom related to
-fsection-anchors we had found and should be fixed by the static array
padding commit.

If you try it on ARM without this test, please also try compilling
druntime with -fno-section-anchors, as this really sounds like the same
old problem.

But it's weird, I've run hello worlds and more advanced applications
(dustmite) with those changes and everything worked fine.

Ack, my fault. I ran the patch on the ARM VM I set-up. But not in the
debootstrap-chroot that I eventually switched to because compilation was
just taking too long... let's do this again... :-)

[ibuclaw]

This is the only thing itching me at the moment.

This code above: relayout_decl (t); guarantees that declsize == typesize by zero'ing out DECL_SIZE (t) and re-evaluating it. So that leaves the check for declsize < initsize, which can be changed to typesize < initsize.

if (int_size_in_bytes (TREE_TYPE (t))
    < int_size_in_bytes (TREE_TYPE (DECL_INITIAL (t))))
  {
    internal_error ( ... );
  }

#120 references an old ticketing system, so that part of the comment may be removed in the future.

[jpf91]

OK, I'll change this as soon as I have access to my main laptop again (which should be this weekend)

[ibuclaw]

Right, I'm gonna stamp my LTGM on this. :-)