On 08/19/2017 04:35 AM, Martin Storsjö wrote:
> On Sat, 19 Aug 2017, JonY via Mingw-w64-public wrote:
>
> According to
> https://gcc.gnu.org/onlinedocs/gcc/Preprocessor-Options.html, both
> -undef and -P are options in the gcc frontend driver itself, just like
> -E. The underlying parameter interf
On Sat, 19 Aug 2017, JonY via Mingw-w64-public wrote:
On 08/18/2017 07:57 PM, Martin Storsjö wrote:
Signed-off-by: Martin Storsjö
---
Updated with the new parameters.
---
mingw-w64-crt/Makefile.am | 10 +
mingw-w64-crt/def-include/func.def.in | 42 +
On 08/18/2017 07:57 PM, Martin Storsjö wrote:
> Signed-off-by: Martin Storsjö
> ---
> Updated with the new parameters.
> ---
> mingw-w64-crt/Makefile.am | 10 +
> mingw-w64-crt/def-include/func.def.in | 42
> +++
> 2 files changed, 52 insertion
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
Signed-off-by: Martin Storsjö
---
Updated with the new parameters.
---
mingw-w64-crt/Makefile.am | 10 +
mingw-w64-crt/def-include/func.def.in | 42 +++
2 files changed, 52 insertions(+)
create mode 100644 mingw-w64-crt/def-include/func.def.in
>
> 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
LGTM
On Fri, Aug 18, 2017 at 2:51 PM, Martin Storsjö wrote:
> Use -undef to avoid any compiler specific predefined definitions,
> and use -P to skip the line markers - removing the need for the extra
> sed command.
>
> The -w command to silence warnings is necessary, since otherwise
> there are
Use -undef to avoid any compiler specific predefined definitions,
and use -P to skip the line markers - removing the need for the extra
sed command.
The -w command to silence warnings is necessary, since otherwise
there are unnecessary warnings like these:
lib64/msvcrt.def.in:66:37: warning: missi
On Fri, 18 Aug 2017, JonY via Mingw-w64-public wrote:
On 08/17/2017 12:14 PM, Martin Storsjö wrote:
Signed-off-by: Martin Storsjö
---
mingw-w64-crt/Makefile.am | 10 +
mingw-w64-crt/def-include/func.def.in | 42 +++
2 files changed, 52 inser
On 08/17/2017 12:14 PM, Martin Storsjö wrote:
> Signed-off-by: Martin Storsjö
> ---
> mingw-w64-crt/Makefile.am | 10 +
> mingw-w64-crt/def-include/func.def.in | 42
> +++
> 2 files changed, 52 insertions(+)
> create mode 100644 mingw-w64-crt/
27 matches
Mail list logo
