Microsoft just published an article about this kind of thing:
https://blogs.msdn.microsoft.com/oldnewthing/20170927-00/?p=97095
It seems that casting pointers to uintptr_t before comparing them
would probably be safe.
--David Grayson
On Sat, Aug 5, 2017 at 12:44 PM, David Grayson wrote:
> What
Martell: OK, I looked at that link briefly. I think I understand what
you're worried about here: the markers that we have at the beginning
and end of our constructor/destructor sections might be removed by the
linker of clang or GCC if it is determined that no code is actually
referencing those va
Hey David,
I came across this today which might be of interest to our discussion,
while it is not related directly to the problem you mentioned it is similar.
https://reviews.llvm.org/D37059
I will follow up with a patch for binutils to add __CTOR_END__ and
__DTOR_END__ but it is interesting to no
On Tue, 22 Aug 2017, Martell Malone wrote:
pushed to master.
Fantastic, thanks!
// Martin
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
pushed to master.
Thanks Martin.
On Fri, Aug 18, 2017 at 9:01 PM, Martin Storsjö wrote:
> On Fri, 18 Aug 2017, Martell Malone wrote:
>
> Can I land this in master?
>>
>
> Ok with me at least. Since it's all within clang ifdefs, it shouldn't hurt
> for any others than us who run this
> still-(bu
On Fri, 18 Aug 2017, Martell Malone wrote:
Can I land this in master?
Ok with me at least. Since it's all within clang ifdefs, it shouldn't hurt
for any others than us who run this
still-(but-hopefully-not-for-long)-experimental setup.
// Martin
---
Can I land this in master?
Best,
Martell
On Fri, Aug 18, 2017 at 8:53 PM, Martell Malone
wrote:
> I'm not so sure; a normal C struct or array would never have a global
>> symbol defined in the middle or at the end, so a smart compiler might
>> some day assume that if you take a symbol and decre
>
> I'm not so sure; a normal C struct or array would never have a global
> symbol defined in the middle or at the end, so a smart compiler might
> some day assume that if you take a symbol and decrement it, it's an
> invalid pointer. I don't really want to argue much more than that,
> and I don't
On Fri, 18 Aug 2017, Martell Malone wrote:
Attached updated patch.
I was itching to invert the .ctors markers so that I could do while (*p)
instead of while (*p != (func_ptr) -1)
but that would create another binutils breakage so I left it.
Let me know how you all want to proceed :)
Looks gr
Attached updated patch.
I was itching to invert the .ctors markers so that I could do while (*p)
instead of while (*p != (func_ptr) -1)
but that would create another binutils breakage so I left it.
Let me know how you all want to proceed :)
On Fri, Aug 18, 2017 at 8:39 PM, David Grayson
wrote:
On Fri, Aug 18, 2017 at 12:26 PM, Martin Storsjö wrote:
> Yup, that resolves the concern.
>
> As long as you just use one or the other of *_LIST__ or *_END__ in each
> function and use the sentinel values instead of comparing the pointers, it
> should be fine. Otherwise the compiler is free to reg
On Fri, 18 Aug 2017, Martell Malone wrote:
LGTM, although it might be good to adjust it in the way David suggested
(avoiding the direct comparisons with *_END__, which is technically
undefined behaviour, and just checking the sentinel element value instead).
I have seen __CTOR_END__ used and
>
> LGTM, although it might be good to adjust it in the way David suggested
> (avoiding the direct comparisons with *_END__, which is technically
> undefined behaviour, and just checking the sentinel element value instead).
I have seen __CTOR_END__ used and counted backwards by many crt startups.
On Fri, 18 Aug 2017, Martell Malone wrote:
Marin, please review :)
commit 726ed8e9b9eea9a2c62c46108da9e014b85dca45
Author: Martell Malone
Date: Fri Aug 18 19:59:20 2017 +0100
crt: Handle .ctors and .dtors within mingw-w64
When building with clang we currently assume you will be
li
Thanks for the explanation of the binutils bug, Martell.
Also, your latest patch has bad newlines inserted by GMail again. It
might actually be better to use GMail's HTML mode, or just use an
attachment with a .txt extension (not .patch).
--David
On Fri, Aug 18, 2017 at 12:05 PM, Martell Malone
I typed too fast *martin :)
On Fri, Aug 18, 2017 at 8:04 PM, Martell Malone wrote:
> Marin, please review :)
>
> commit 726ed8e9b9eea9a2c62c46108da9e014b85dca45
> Author: Martell Malone
> Date: Fri Aug 18 19:59:20 2017 +0100
>
> crt: Handle .ctors and .dtors within mingw-w64
>
> When b
Marin, please review :)
commit 726ed8e9b9eea9a2c62c46108da9e014b85dca45
Author: Martell Malone
Date: Fri Aug 18 19:59:20 2017 +0100
crt: Handle .ctors and .dtors within mingw-w64
When building with clang we currently assume you will be
linking with llvm's lld or a bleeding edge bi
In that case I will be back with a patch shortly for you to review.
It might look ugly because of a large __clang__ ifdef block but should work.
On Fri, Aug 18, 2017 at 7:50 PM, Martin Storsjö wrote:
> On Fri, 18 Aug 2017, Martell Malone wrote:
>
> David, I also want to remove KEEP (*(.ctors));
On Fri, 18 Aug 2017, Martell Malone wrote:
David, I also want to remove KEEP (*(.ctors)); which seems to cause a bug
when linking in conjunction with KEEP (*(SORT_BY_NAME(.ctors.*))) and our
new mingw-w64 markers. I have details in this email on binutils ml.
https://sourceware.org/ml/binutils/20
David, Sorry the previous email was to the thread, this link is to the
exact email where I detail the problem.
https://sourceware.org/ml/binutils/2017-08/msg00123.html
On Fri, Aug 18, 2017 at 7:46 PM, Martell Malone
wrote:
> David, I also want to remove KEEP (*(.ctors)); which seems to cause a b
David, I also want to remove KEEP (*(.ctors)); which seems to cause a bug
when linking in conjunction with KEEP (*(SORT_BY_NAME(.ctors.*))) and our
new mingw-w64 markers. I have details in this email on binutils ml.
https://sourceware.org/ml/binutils/2017-08/msg00078.html
I have to create a minifie
On Fri, 18 Aug 2017, Martell Malone wrote:
suddenly requiring the absolutely latest binutils, right?
Correct we will need the next binutils release as a min version.
I don't think we need a condition we should just specify a new min binutils
version for mingw-w64 to require.
jon_y said this t
Martell, what was wrong with the sorting in the old binutils? It
seems like the only thing you're doing is changing "SORT" to
"SORT_BY_NAME" but I couldn't easily tell if that will make a
difference.
--David
On Fri, Aug 18, 2017 at 11:11 AM, Martell Malone
wrote:
>>
>> suddenly requiring the a
>
> suddenly requiring the absolutely latest binutils, right?
Correct we will need the next binutils release as a min version.
I don't think we need a condition we should just specify a new min binutils
version for mingw-w64 to require.
jon_y said this to me in the past, I think we should wait un
On Mon, 14 Aug 2017, Martell Malone wrote:
Can you briefly summarize what change this does and why it's necessary,
since the plain mingw patch as such seems to work already both with
binutils ld and with lld? Is it in order to guarantee that the symbols in
the mingw patch are sorted correctly s
>
> Can you briefly summarize what change this does and why it's necessary,
> since the plain mingw patch as such seems to work already both with
> binutils ld and with lld? Is it in order to guarantee that the symbols in
> the mingw patch are sorted correctly so that we can be sure that the
> mark
On Mon, 14 Aug 2017, Martell Malone wrote:
Hey Martin,
I had a discussion with Nick and CC'd kai on getting the binutils patch in
tree a week ago.
https://sourceware.org/ml/binutils/2017-08/msg00123.html
It seems to be moving along.
Oh, I see - ok.
Can you briefly summarize what change this
Hey Martin,
I had a discussion with Nick and CC'd kai on getting the binutils patch in
tree a week ago.
https://sourceware.org/ml/binutils/2017-08/msg00123.html
It seems to be moving along.
Best,
Martell
On Mon, Aug 14, 2017 at 8:49 AM, Martin Storsjö wrote:
> On Sat, 5 Aug 2017, David Grays
On Sat, 5 Aug 2017, David Grayson wrote:
Oops, here is the patch.
On Sat, Aug 5, 2017 at 10:14 AM, David Grayson wrote:
I think Martell's last patch would have worked but it's not as safe as
I would like it to be. I think the constructor and destructor lists
should not be defined in gccmain.
I thought my last email explained it pretty well. The optimizer can
do any kind of transformation it wants on the code as long as it
doesn't change the behavior of well-defined programs. You seem to be
stuck on the "__used__" attribute but that's not relevant to my
argument.
--David
On Sun, Aug
>
> What I meant is that if GCC's optimizer ever figures out that we are
> comparing pointers that came from two different memory objects, it
> would know we are doing undefined behavior and would have a license to
> do whatever it wants, including removing that code. The way the loop
> is written
What I meant is that if GCC's optimizer ever figures out that we are
comparing pointers that came from two different memory objects, it
would know we are doing undefined behavior and would have a license to
do whatever it wants, including removing that code. The way the loop
is written right now i
>
> I think Martell's last patch would have worked but it's not as safe as
> I would like it to be. I think the constructor and destructor lists
should not be defined in gccmain.c where they are used, because then
> the compiler optimizer might start to get smart and stop optimizing
> things in a
Oops, here is the patch.
On Sat, Aug 5, 2017 at 10:14 AM, David Grayson wrote:
> I think Martell's last patch would have worked but it's not as safe as
> I would like it to be. I think the constructor and destructor lists
> should not be defined in gccmain.c where they are used, because then
> t
I think Martell's last patch would have worked but it's not as safe as
I would like it to be. I think the constructor and destructor lists
should not be defined in gccmain.c where they are used, because then
the compiler optimizer might start to get smart and stop optimizing
things in a bad way.
Hey David,
> Your binutils patch did not apply cleanly to binutils-2.27 but I got
> it to work. It looks pretty dangerous to me because you removed the
> lines for keeping the .dtors, .dtor, .ctors, and .ctor sections. And
> you're using .ctors and .dtors in your other patch, and other code
> m
With your latest two patches, the toolchain compiles but I get an
error when building a shared library:
/nix/store/k481dhv5hivggnjyb9rs95fz1k6ylhjz-mingw-w64-2017-08-03-i686-w64-mingw32/lib/../lib/libmingw32.a(lib32_libmingw32_a-gccmain.o):
In function `_do_global_dtors':
/tmp/nix-build-mingw-w64-
Oh, I mean that I got the patch to apply, but I don't know if it
really *works*; the toolchain is still building at this time. --David
On Fri, Aug 4, 2017 at 6:11 PM, David Grayson wrote:
> Your binutils patch did not apply cleanly to binutils-2.27 but I got
> it to work. It looks pretty danger
Your binutils patch did not apply cleanly to binutils-2.27 but I got
it to work. It looks pretty dangerous to me because you removed the
lines for keeping the .dtors, .dtor, .ctors, and .ctor sections. And
you're using .ctors and .dtors in your other patch, and other code
might use them too I sup
Hey David,
This could be caused by gcc including it's own crtbegin.o and crtend.o
I managed to install a toolchain with brew and I swapped out gcc's and
mingw-w64's crtbegin and crtend.
Everything seems to work here as intended.
Attached is an updated patch that avoids crtbegin and crtend that sho
Martell:
My setup ( https://github.com/DavidEGrayson/nixcrpkgs ) makes it quite
easy to try random patches and make sure that GCC can still be
bootstrapped and that I can build non-trivial applications. I tried
your patch (after fixing the linebreaks added by GMail) but
unfortunately it doesn't w
Okay lets just solve this.
I believe the following should work for both clang and gcc
I added a test case at the bottom also.
diff --git a/mingw-w64-crt/crt/crtbegin.c b/mingw-w64-crt/crt/crtbegin.c
index 39c0d856..1672f7b9 100644
--- a/mingw-w64-crt/crt/crtbegin.c
+++ b/mingw-w64-crt/crt/crtbegin
On Fri, 4 Aug 2017, Ruben Van Boxem wrote:
Op 3 aug. 2017 9:26 p.m. schreef "Martell Malone" :
I for one would like to be able to use one crt with both Clang and GCC. No
use in duplicating 99% of the code for that one little bit of startup code
that needs to be different. Perhaps ldd or Clang n
Hello. Bellow my signature is a copy of the explanation I sent to the
list about why ca451a7 should be reverted.
The issue is that different objects are adding constructor pointers to
a special section for it, and the CRT need to reliably find the
beginning of that section. The CRT uses special
On Thu, 3 Aug 2017, Martell Malone wrote:
Hey Martin,
Glad to see you following up on my various LLVM adventures :)
From what I remember the initialization is done in mingw-w64/crt/gccmain.c.
I believe it may be possible to add this code and not make is clang
specific.
Before the iteration lo
Op 3 aug. 2017 9:26 p.m. schreef "Martell Malone" :
Hey Martin,
Glad to see you following up on my various LLVM adventures :)
From what I remember the initialization is done in mingw-w64/crt/gccmain.c.
I believe it may be possible to add this code and not make is clang
specific.
Before the iter
Hey Martin,
Glad to see you following up on my various LLVM adventures :)
From what I remember the initialization is done in mingw-w64/crt/gccmain.c.
I believe it may be possible to add this code and not make is clang
specific.
Before the iteration loop check in __do_global_ctors
and __do_global
Hi Martell, André and Kai,
On Sun, 28 Aug 2016, André Hentschel wrote:
Am 09.08.2016 um 11:16 schrieb Kai Tietz:
Hallo Martell,
patch is ok. Wouldn't it be better to have those symbols in linker
scrpt instead? That is actually the way used in ld for it.
Thanlks,
Kai
2016-08-06 5:14 GMT+02
Am 09.08.2016 um 11:16 schrieb Kai Tietz:
> Hallo Martell,
>
> patch is ok. Wouldn't it be better to have those symbols in linker
> scrpt instead? That is actually the way used in ld for it.
>
> Thanlks,
> Kai
>
> 2016-08-06 5:14 GMT+02:00 Martell Malone :
>> This patch should be the last piec
Hallo Martell,
patch is ok. Wouldn't it be better to have those symbols in linker
scrpt instead? That is actually the way used in ld for it.
Thanlks,
Kai
2016-08-06 5:14 GMT+02:00 Martell Malone :
> This patch should be the last piece of the puzzle.
> Now c++ works, it relied heavily on ctors
This patch should be the last piece of the puzzle.
Now c++ works, it relied heavily on ctors which was broken with clang and
lld.
please review
From 077f2318a219db191588d0ab00df58bb694c2931 Mon Sep 17 00:00:00 2001
From: Martell Malone
Date: Fri, 5 Aug 2016 20:09:41 -0700
Subject: [PATCH] Handle
51 matches
Mail list logo
