Re: [Bug 126] Add support for attribute to mark data as volatile.
Am Wed, 16 Jul 2014 14:41:42 +0100
schrieb Iain Buclaw via D.gnu d.gnu@puremagic.com:
On 16 July 2014 14:10, Johannes Pfau via D.gnu d.gnu@puremagic.com
wrote:
Am Wed, 16 Jul 2014 05:53:30 +
schrieb Timo Sintonen t.sinto...@luukku.com:
On Tuesday, 24 June 2014 at 14:14:18 UTC, Johannes Pfau wrote:
I think we should at least try to bring this to the main
newsgroup,
I told you this is not going to work. The decision seems to be
made even when the conversion is still going on. Lets just make
this into gdc so we can continue the real work. When this is
ready and working, we may try again.
Unfortunately I am not skilled enough to implement this into the
compiler so I have to ask somebody else to do it. I will test it
as soon it is possible.
This has even more importance now because I have understood that
dmd will disallow read-modify-write access to shared variables. I
hope this feature is not brought to gdc before volatile is
working.
I didn't have any high expectations, nevertheless we had to try.
Well I could implement the DIP for GDC, but this is against the
vision of a shared frontend. In the end Iain has to decide what to
do.
I'm not sure if I'd implement Volatile!T though. It's probably lots
of work and there's no guarantee it'll work at all in the end. The
more I think about it the more corner cases come to mind which all
need to be worked around.
Keeping only peek/poke as Walter suggests of course also has
drawbacks. peek/poke plus Mike's wrapper is probably the best we'll
get from DMD.
Btw: @Iain if we implement these peek/poke things I think
asm{ : : :memory;} is not good enough. At least it's being
removed in some tests and according to some sources it only affect
operations on volatile variables... So we'd have to implement
peek/poke on top of C/GCC volatile.
Wouldn't a reinterpret cast (VIEW_CONVERT_EXPR) to volatile be enough?
Something akin to:
T peek(T var) { return *(volatile T*)var; }
T poke(T var, T val) { return *(volatile T*)var = *(volatile
T*)val; }
Yes I guess this should work. I just meant that a library solution with
compiler barriers would probably not work.
--gc-sections and GDC
I received a question from Dicebot in at the end of my
presentation. He asked about the --gc-sections linker flag
breaking code from GDC.
I recently discovered how one can see why this is occurring, and
I hope this will help identify the problem and lead to a solution.
Compile any simple hello world program with the following gcc
command:
gcc --verbose -Wl,--verbose test.c.
Part of the output is GCC's internal linker script as shown
below. I believe this is the source of the problem. Here's my
theory.
D is not C, and is likely generating code that the GCC internal
linker script doesn't know about. This code may be incorrectly
identified as dead code because there is no 'link' to it and,
therefore, appears unused. If D or GDC is generating any code
like this, it needs to be marked as KEEP in the linker script.
You can see examples of this in GCC's internal linker script
below.
If my theory is correct, GDC may have to make an internal linker
script specifically for D's code generation that marks such code
as KEEP.
I hope I'm not just blowing smoke.
Mike
==
/* Script for -z combreloc: combine and sort reloc sections */
OUTPUT_FORMAT(elf64-x86-64, elf64-x86-64,
elf64-x86-64)
OUTPUT_ARCH(i386:x86-64)
ENTRY(_start)
SEARCH_DIR(/usr/x86_64-unknown-linux-gnu/lib64);
SEARCH_DIR(/usr/x86_64-unknown-linux-gnu/lib);
SEARCH_DIR(/usr/lib); SEARCH_DIR(/usr/local/lib);
SECTIONS
{
/* Read-only sections, merged into text segment: */
PROVIDE (__executable_start = SEGMENT_START(text-segment,
0x40)); . = SEGMENT_START(text-segment, 0x40) +
SIZEOF_HEADERS;
.interp : { *(.interp) }
.note.gnu.build-id : { *(.note.gnu.build-id) }
.hash : { *(.hash) }
.gnu.hash : { *(.gnu.hash) }
.dynsym : { *(.dynsym) }
.dynstr : { *(.dynstr) }
.gnu.version: { *(.gnu.version) }
.gnu.version_d : { *(.gnu.version_d) }
.gnu.version_r : { *(.gnu.version_r) }
.rela.dyn :
{
*(.rela.init)
*(.rela.text .rela.text.* .rela.gnu.linkonce.t.*)
*(.rela.fini)
*(.rela.rodata .rela.rodata.* .rela.gnu.linkonce.r.*)
*(.rela.data .rela.data.* .rela.gnu.linkonce.d.*)
*(.rela.tdata .rela.tdata.* .rela.gnu.linkonce.td.*)
*(.rela.tbss .rela.tbss.* .rela.gnu.linkonce.tb.*)
*(.rela.ctors)
*(.rela.dtors)
*(.rela.got)
*(.rela.bss .rela.bss.* .rela.gnu.linkonce.b.*)
*(.rela.ldata .rela.ldata.* .rela.gnu.linkonce.l.*)
*(.rela.lbss .rela.lbss.* .rela.gnu.linkonce.lb.*)
*(.rela.lrodata .rela.lrodata.* .rela.gnu.linkonce.lr.*)
*(.rela.ifunc)
}
.rela.plt :
{
*(.rela.plt)
PROVIDE_HIDDEN (__rela_iplt_start = .);
*(.rela.iplt)
PROVIDE_HIDDEN (__rela_iplt_end = .);
}
.init :
{
KEEP (*(SORT_NONE(.init)))
}
.plt: { *(.plt) *(.iplt) }
.text :
{
*(.text.unlikely .text.*_unlikely .text.unlikely.*)
*(.text.exit .text.exit.*)
*(.text.startup .text.startup.*)
*(.text.hot .text.hot.*)
*(.text .stub .text.* .gnu.linkonce.t.*)
/* .gnu.warning sections are handled specially by elf32.em.
*/
*(.gnu.warning)
}
.fini :
{
KEEP (*(SORT_NONE(.fini)))
}
PROVIDE (__etext = .);
PROVIDE (_etext = .);
PROVIDE (etext = .);
.rodata : { *(.rodata .rodata.* .gnu.linkonce.r.*) }
.rodata1: { *(.rodata1) }
.eh_frame_hdr : { *(.eh_frame_hdr) }
.eh_frame : ONLY_IF_RO { KEEP (*(.eh_frame)) }
.gcc_except_table : ONLY_IF_RO { *(.gcc_except_table
.gcc_except_table.*) }
/* These sections are generated by the Sun/Oracle C++ compiler.
*/
.exception_ranges : ONLY_IF_RO { *(.exception_ranges
.exception_ranges*) }
/* Adjust the address for the data segment. We want to adjust
up to
the same address within the page on the next page up. */
. = ALIGN (CONSTANT (MAXPAGESIZE)) - ((CONSTANT (MAXPAGESIZE) -
.) (CONSTANT (MAXPAGESIZE) - 1)); . = DATA_SEGMENT_ALIGN
(CONSTANT (MAXPAGESIZE), CONSTANT (COMMONPAGESIZE));
/* Exception handling */
.eh_frame : ONLY_IF_RW { KEEP (*(.eh_frame)) }
.gcc_except_table : ONLY_IF_RW { *(.gcc_except_table
.gcc_except_table.*) }
.exception_ranges : ONLY_IF_RW { *(.exception_ranges
.exception_ranges*) }
/* Thread Local Storage sections */
.tdata : { *(.tdata .tdata.* .gnu.linkonce.td.*) }
.tbss : { *(.tbss .tbss.* .gnu.linkonce.tb.*)
*(.tcommon) }
.preinit_array :
{
PROVIDE_HIDDEN (__preinit_array_start = .);
KEEP (*(.preinit_array))
PROVIDE_HIDDEN (__preinit_array_end = .);
}
.init_array :
{
PROVIDE_HIDDEN (__init_array_start = .);
KEEP (*(SORT_BY_INIT_PRIORITY(.init_array.*)
SORT_BY_INIT_PRIORITY(.ctors.*)))
KEEP (*(.init_array EXCLUDE_FILE (*crtbegin.o *crtbegin?.o
*crtend.o *crtend?.o ) .ctors))
PROVIDE_HIDDEN
Re: --gc-sections and GDC
On 16/07/14 15:52, Mike wrote: I received a question from Dicebot in at the end of my presentation. He asked about the --gc-sections linker flag breaking code from GDC. Have you seen this post: http://forum.dlang.org/thread/lbrfycmutwrrghtza...@forum.dlang.org ? -- /Jacob Carlborg
Re: --gc-sections and GDC
Am Wed, 16 Jul 2014 15:35:09 +0100 schrieb Iain Buclaw via D.gnu d.gnu@puremagic.com: On 16 July 2014 15:12, Mike via D.gnu d.gnu@puremagic.com wrote: On Wednesday, 16 July 2014 at 13:52:57 UTC, Mike wrote: I received a question from Dicebot in at the end of my presentation. He asked about the --gc-sections linker flag breaking code from GDC. I recently discovered how one can see why this is occurring, and I hope this will help identify the problem and lead to a solution. Compile any simple hello world program with the following gcc command: gcc --verbose -Wl,--verbose test.c. Part of the output is GCC's internal linker script as shown below. I believe this is the source of the problem. Here's my theory. D is not C, and is likely generating code that the GCC internal linker script doesn't know about. This code may be incorrectly identified as dead code because there is no 'link' to it and, therefore, appears unused. If D or GDC is generating any code like this, it needs to be marked as KEEP in the linker script. You can see examples of this in GCC's internal linker script below. If my theory is correct, GDC may have to make an internal linker script specifically for D's code generation that marks such code as KEEP. I hope I'm not just blowing smoke. Mike And I just checked with GDC... gdc --verbose -Wl,--verbose test.d ... and the internal linker script is exactly the same as the C version. That doesn't seem right to me. I would expect them to be at least a little different. Mike Using a D-specific linker script in is outside the scope of GDC itself. I'd have to make a patch to Binutils. And yes, a bespoke linker script would solve many problems that are currently managed by the compiler. Regards Iain Please don't start working on a D specific linker script, cause I'm already working on that ;-) I've only done moduleinfo so far, but TLS is next, then shared library support.
Re: --gc-sections and GDC
On 16 July 2014 21:03, Johannes Pfau via D.gnu d.gnu@puremagic.com wrote: Am Wed, 16 Jul 2014 15:35:09 +0100 schrieb Iain Buclaw via D.gnu d.gnu@puremagic.com: On 16 July 2014 15:12, Mike via D.gnu d.gnu@puremagic.com wrote: On Wednesday, 16 July 2014 at 13:52:57 UTC, Mike wrote: I received a question from Dicebot in at the end of my presentation. He asked about the --gc-sections linker flag breaking code from GDC. I recently discovered how one can see why this is occurring, and I hope this will help identify the problem and lead to a solution. Compile any simple hello world program with the following gcc command: gcc --verbose -Wl,--verbose test.c. Part of the output is GCC's internal linker script as shown below. I believe this is the source of the problem. Here's my theory. D is not C, and is likely generating code that the GCC internal linker script doesn't know about. This code may be incorrectly identified as dead code because there is no 'link' to it and, therefore, appears unused. If D or GDC is generating any code like this, it needs to be marked as KEEP in the linker script. You can see examples of this in GCC's internal linker script below. If my theory is correct, GDC may have to make an internal linker script specifically for D's code generation that marks such code as KEEP. I hope I'm not just blowing smoke. Mike And I just checked with GDC... gdc --verbose -Wl,--verbose test.d ... and the internal linker script is exactly the same as the C version. That doesn't seem right to me. I would expect them to be at least a little different. Mike Using a D-specific linker script in is outside the scope of GDC itself. I'd have to make a patch to Binutils. And yes, a bespoke linker script would solve many problems that are currently managed by the compiler. Regards Iain Please don't start working on a D specific linker script, cause I'm already working on that ;-) I've only done moduleinfo so far, but TLS is next, then shared library support. I wish I could clone you.
