GNU = Junkware

[Dave Blanchard]

No, I'm not trolling, just venting here for a moment. So sick of garbage ass, 
crusty junkware that's always a battle to the death to accomplish anything.

I really understand where Liu Hao was coming from yesterday when he was in here 
raging against the AT&T assembler. I could sense the bitterness and disgust in 
him, the kind that can only come from a lifetime of bitter disappointment in 
the status quo. It's like he's just as sick and tired as I am of broken ass, 
buggy software.

GNU GCC/GLIBC IS THE MOST PAINFUL PIECE OF SHIT FUCKING SOFTWARE ON THE PLANET 
TO BOOTSTRAP.

Not even the flaming pile of dogshit that is PYTHON comes close to the misery 
and hell awaiting any hapless person who wants to accomplish what ought to be 
the Simple And Straightforward Fucking Task of bootstrapping a cross-compiled 
GNU gcc/glibc/binutils system.

I have been working on this project FOR AN ENTIRE YEAR and the pain just never 
seems to end. 

I've encountered every shitty, stupid, inane, puzzling, worthless, completely 
nonsensical error message that could possibly be generated by a piece of 
software, which almost NEVER leads toward figuring out exactly went wrong, but 
usually just deeper into the quagmire.

Seemingly the only way that will ever finally get this junk working is to just 
sit there randomly trying different stuff in the hope that it somehow moves one 
closer toward getting something that works right. 

/rant

-- 
Dave Blanchard 

Re: GNU = Junkware

[Jonathan Wakely via Gcc]

Cool story bro

On Sat, 26 Nov 2022, 09:20 Dave Blanchard,  wrote:

> No, I'm not trolling, just venting here for a moment. So sick of garbage
> ass, crusty junkware that's always a battle to the death to accomplish
> anything.
>
> I really understand where Liu Hao was coming from yesterday when he was in
> here raging against the AT&T assembler. I could sense the bitterness and
> disgust in him, the kind that can only come from a lifetime of bitter
> disappointment in the status quo. It's like he's just as sick and tired as
> I am of broken ass, buggy software.
>
> GNU GCC/GLIBC IS THE MOST PAINFUL PIECE OF SHIT FUCKING SOFTWARE ON THE
> PLANET TO BOOTSTRAP.
>
> Not even the flaming pile of dogshit that is PYTHON comes close to the
> misery and hell awaiting any hapless person who wants to accomplish what
> ought to be the Simple And Straightforward Fucking Task of bootstrapping a
> cross-compiled GNU gcc/glibc/binutils system.
>
> I have been working on this project FOR AN ENTIRE YEAR and the pain just
> never seems to end.
>
> I've encountered every shitty, stupid, inane, puzzling, worthless,
> completely nonsensical error message that could possibly be generated by a
> piece of software, which almost NEVER leads toward figuring out exactly
> went wrong, but usually just deeper into the quagmire.
>
> Seemingly the only way that will ever finally get this junk working is to
> just sit there randomly trying different stuff in the hope that it somehow
> moves one closer toward getting something that works right.
>
> /rant
>
> --
> Dave Blanchard 
>

Re: -fanalyzer: Questions on C vs CPP + use of GCC attr's like malloc()/access()

[Jonathan Wakely via Gcc]

On Fri, 25 Nov 2022, 18:55 Gavin Ray via Gcc,  wrote:

>
> On a related note, the "fd" analyzers warn: "fd may not be valid" but don't
> clarify what "valid" means.
>

A valid file descriptor is one that was returned by the C library and
refers to an open file. That's not something GCC defines.


> I found the DOT diagrams in the analyzer source and it turns out that the
> key is
> to check "if (fd >= 0)".


The point is that the OS functions that return a new file descriptor return
a negative value on error, so all valid file descriptors are non-negative.
But not all non-negative integers are valid file descriptors.

You should check for errors when calling open, dup2, socket etc. so you
know whether it succeeded.


Maybe this could be added to the "fd" analyzer
> warnings/info, too?
>

I don't think that's a good idea unless word carefully, it's not as simple
as "test if it's non-negative". You should check for errors when using OS
APIs, but that's always true, it's not difficult to the analyzer output.



>
>
>
>

Re: GNU = Junkware

[Paul Smith]

On Sat, 2022-11-26 at 03:20 -0600, Dave Blanchard wrote:
> GNU GCC/GLIBC IS THE MOST PAINFUL PIECE OF SHIT FUCKING SOFTWARE ON
> THE PLANET TO BOOTSTRAP.

Seems like a good time to remember the old adage, if you think everyone
else is the asshole then you should consider that it's really you who's
the asshole.  If it's taken a full year and you're not done yet, maybe
you're just not suited to this type of work.  I'm not trolling either:
it's not for everyone and that's fine.  There's lots of things to do
and you'd probably be happier doing something else.

> Seemingly the only way that will ever finally get this junk working
> is to just sit there randomly trying different stuff in the hope that
> it somehow moves one closer toward getting something that works
> right.

Yes, I believe you've proved my guess correct here.

Re: Can't build Ada

[Paul Koning via Gcc]

> On Nov 25, 2022, at 3:46 PM, Iain Sandoe  wrote:
> 
> Hi Paul,
> 
>> On 25 Nov 2022, at 20:13, Andrew Pinski via Gcc  wrote:
>> 
>> On Fri, Nov 25, 2022 at 12:08 PM Paul Koning  wrote:
>>> 
 On Nov 25, 2022, at 3:03 PM, Andrew Pinski  wrote:
 
 On Fri, Nov 25, 2022 at 11:59 AM Paul Koning via Gcc  
 wrote:
> 
> I'm trying to use fairly recent GCC sources (the gcc-darwin branch to be 
> precise) to build Ada, starting with the latest (2020) release of Gnat 
> from Adacore.
 
 Are you building a cross compiler or a native compiler?
 If you are building a cross, you need to bootstrap a native compiler first.
>>> 
>>> I'm not sure.  The installed Gnat is x86_64-darwin; I want to build 
>>> aarch64-darwin.
>> 
>> You have to build a x86_64-darwin compiler first with the same sources
>> as you are building for aarch64-darwin.
> 
> So .. 
> 1/ if you are on arm64 Darwin, 
>  - the first step is to bootstrap the compiler using Rosetta 2 and the 
> available x86_64 gnat.
> 
> 2/ if you are on x86_64 Darwin…
>  - the first step is to bootstrap the compiler using the available x86-64 
> gnat.

Thanks all.

I tried that (#1) and got the same failure.  The trouble seems to be that the 
current sources have Ada2020 constructs in them and the available Gnat doesn't 
support that version.  The commit that introduces these (or some of them at 
least) is 91d68769419b from Feb 4, 2022.

So I'm guessing I'll have to do this in two parts, first build a newer but 
not-latest Gnat from a release that doesn't include the problematic constructs, 
then follow that by using the intermediate to build the current sources.

I wonder if this incompatibility was intentional.  If not it would be good for 
the Ada maintainers to fix these and ensure that the current code can still be 
built with the most recent public release of Gnat.  Conversely, if it is 
intentional, the documentation should be updated to explain how to build the 
current code.

paul

Re: -fanalyzer: Questions on C vs CPP + use of GCC attr's like malloc()/access()

[Gavin Ray via Gcc]

I was using if (fd != -1) and was still getting the warning which confused me
My suggestion was maybe to add the exact condition the fd analyzer is
looking for to the warning so that folks know how to fix it/trigger
its 'true' branch.

e.g. instead of:
"fd may not be valid"

Something like this, or thereabouts:
"fd may not be valid (expecting fd >= 0)"

On Sat, Nov 26, 2022 at 9:09 AM Jonathan Wakely  wrote:
>
>
>
> On Fri, 25 Nov 2022, 18:55 Gavin Ray via Gcc,  wrote:
>>
>>
>> On a related note, the "fd" analyzers warn: "fd may not be valid" but don't
>> clarify what "valid" means.
>
>
> A valid file descriptor is one that was returned by the C library and refers 
> to an open file. That's not something GCC defines.
>
>>
>> I found the DOT diagrams in the analyzer source and it turns out that the 
>> key is
>> to check "if (fd >= 0)".
>
>
> The point is that the OS functions that return a new file descriptor return a 
> negative value on error, so all valid file descriptors are non-negative. But 
> not all non-negative integers are valid file descriptors.
>
> You should check for errors when calling open, dup2, socket etc. so you know 
> whether it succeeded.
>
>
>> Maybe this could be added to the "fd" analyzer
>> warnings/info, too?
>
>
> I don't think that's a good idea unless word carefully, it's not as simple as 
> "test if it's non-negative". You should check for errors when using OS APIs, 
> but that's always true, it's not difficult to the analyzer output.
>
>
>>
>>
>>
>>

Re: Can't build Ada

[Iain Sandoe]

Hi Paul,

> On 26 Nov 2022, at 15:48, Paul Koning via Gcc  wrote:

>> On Nov 25, 2022, at 3:46 PM, Iain Sandoe  wrote:
>> 

>>> On 25 Nov 2022, at 20:13, Andrew Pinski via Gcc  wrote:
>>> 
>>> On Fri, Nov 25, 2022 at 12:08 PM Paul Koning  wrote:
 
> On Nov 25, 2022, at 3:03 PM, Andrew Pinski  wrote:
> 
> On Fri, Nov 25, 2022 at 11:59 AM Paul Koning via Gcc  
> wrote:
>> 
>> I'm trying to use fairly recent GCC sources (the gcc-darwin branch to be 
>> precise) to build Ada, starting with the latest (2020) release of Gnat 
>> from Adacore.
> 
> Are you building a cross compiler or a native compiler?
> If you are building a cross, you need to bootstrap a native compiler 
> first.
 
 I'm not sure.  The installed Gnat is x86_64-darwin; I want to build 
 aarch64-darwin.
>>> 
>>> You have to build a x86_64-darwin compiler first with the same sources
>>> as you are building for aarch64-darwin.
>> 
>> So .. 
>> 1/ if you are on arm64 Darwin, 
>> - the first step is to bootstrap the compiler using Rosetta 2 and the 
>> available x86_64 gnat.
>> 
>> 2/ if you are on x86_64 Darwin…
>> - the first step is to bootstrap the compiler using the available x86-64 
>> gnat.
> 
> Thanks all.
> 
> I tried that (#1) and got the same failure.  The trouble seems to be that the 
> current sources have Ada2020 constructs in them and the available Gnat 
> doesn't support that version.  The commit that introduces these (or some of 
> them at least) is 91d68769419b from Feb 4, 2022.

I am part way through the exercise on both macOS 11 (X86) and 12 (Arm64).

** However, I am using gcc-7.5 as the bootstrap compiler, not gcc-5.1.

You might find problems unless you actually start a Rosetta 2 shell - so 
“ arch -x86_64 bash “ 
and then go from there (this seems to ensure that sub-processes are started as 
x86_64)

(with this, bootstrap succeeded for both x86_64 Rosetta 2  and rebased Arm64 
branch native - r13-4309-g309e2d95e3b9)

I will push the rebased arm64 branch when testing is done.

> So I'm guessing I'll have to do this in two parts, first build a newer but 
> not-latest Gnat from a release that doesn't include the problematic 
> constructs, then follow that by using the intermediate to build the current 
> sources.
> 
> I wonder if this incompatibility was intentional.  If not it would be good 
> for the Ada maintainers to fix these and ensure that the current code can 
> still be built with the most recent public release of Gnat.  Conversely, if 
> it is intentional, the documentation should be updated to explain how to 
> build the current code.

The current statement  (https://gcc.gnu.org/install/prerequisites.html) is:

GNAT
In order to build GNAT, the Ada compiler, you need a working GNAT compiler (GCC 
version 5.1 or later).

so, if 5.1 is not working, then perhaps a PR is in order.

cheers
Iain

Re: GNU = Junkware

[Paul Koning via Gcc]

> On Nov 26, 2022, at 4:20 AM, Dave Blanchard  wrote:
> 
> No, I'm not trolling, just venting here for a moment. So sick of garbage ass, 
> crusty junkware that's always a battle to the death to accomplish anything.

I don't know who you are or why you feel a need to spew obscenities on the GCC 
technical mailing list.  Especially since you have never contributed anything 
to GCC.

Please stop.  And to the list overseers: if it doesn't stop, please apply a 
suitable blacklist.

paul

Re: Can't build Ada

[Paul Koning via Gcc]

> On Nov 26, 2022, at 10:58 AM, Iain Sandoe  wrote:
> 
> Hi Paul,
> 
> I am part way through the exercise on both macOS 11 (X86) and 12 (Arm64).
> 
> ** However, I am using gcc-7.5 as the bootstrap compiler, not gcc-5.1.

I'm not using 5.1 -- I only quoted that version number because the install 
documentation mentions it.  The actual bootstrap compiler is 8.4.1:

pkoning:gcc-darwin-x86 pkoning$ /usr/local/gnat/bin/gcc --version
gcc (GCC) 8.4.1 20200430 (for GNAT Community 2020 20200818)

> You might find problems unless you actually start a Rosetta 2 shell - so 
> “ arch -x86_64 bash “ 
> and then go from there (this seems to ensure that sub-processes are started 
> as x86_64)
> 
> (with this, bootstrap succeeded for both x86_64 Rosetta 2  and rebased Arm64 
> branch native - r13-4309-g309e2d95e3b9)
> 
> I will push the rebased arm64 branch when testing is done.
> 
>> So I'm guessing I'll have to do this in two parts, first build a newer but 
>> not-latest Gnat from a release that doesn't include the problematic 
>> constructs, then follow that by using the intermediate to build the current 
>> sources.
>> 
>> I wonder if this incompatibility was intentional.  If not it would be good 
>> for the Ada maintainers to fix these and ensure that the current code can 
>> still be built with the most recent public release of Gnat.  Conversely, if 
>> it is intentional, the documentation should be updated to explain how to 
>> build the current code.
> 
> The current statement  (https://gcc.gnu.org/install/prerequisites.html) is:
> 
> GNAT
> In order to build GNAT, the Ada compiler, you need a working GNAT compiler 
> (GCC version 5.1 or later).
> 
> so, if 5.1 is not working, then perhaps a PR is in order.

I will do that, if the "shell in Rosetta" thing doesn't cure the problem.

paul

Re: Can't build Ada

[Arnaud Charlet via Gcc]

>> The current statement  (https://gcc.gnu.org/install/prerequisites.html) is:
>> 
>> GNAT
>> In order to build GNAT, the Ada compiler, you need a working GNAT compiler 
>> (GCC version 5.1 or later).
>> 
>> so, if 5.1 is not working, then perhaps a PR is in order.
> 
> I will do that, if the "shell in Rosetta" thing doesn't cure the problem.

You won’t need to, the version of gnat you are using is recent enough, you need 
to follow Ian’s instructions to the letter. The Ada 2022 code is a red herring 
and is only problematic when you build a cross with a non matching native, not 
when building a native compiler.

Arno

Re: Can't build Ada

[Iain Sandoe]

> On 26 Nov 2022, at 16:42, Arnaud Charlet  wrote:
> 
> 
>>> The current statement  (https://gcc.gnu.org/install/prerequisites.html) is:
>>> 
>>> GNAT
>>> In order to build GNAT, the Ada compiler, you need a working GNAT compiler 
>>> (GCC version 5.1 or later).
>>> 
>>> so, if 5.1 is not working, then perhaps a PR is in order.
>> 
>> I will do that, if the "shell in Rosetta" thing doesn't cure the problem.
> 
> You won’t need to, the version of gnat you are using is recent enough, you 
> need to follow Ian’s instructions to the letter. The Ada 2022 code is a red 
> herring and is only problematic when you build a cross with a non matching 
> native, not when building a native compiler.

One additional question/point - which branch are you trying to build the cross 
from?

I am sure it will not work from upstream master.

Unfortunately, owing to lack of free time… aarch64-darwin is not yet completely 
ready to upstream, so folks are using the development branch here: 
https://github.com/iains/gcc-darwin-arm64 (which I will update later, based on 
the master version mentioned earlier; if testing goes OK).

Iain.

Re: -fanalyzer: Questions on C vs CPP + use of GCC attr's like malloc()/access()

[Jonathan Wakely via Gcc]

On Sat, 26 Nov 2022, 15:48 Gavin Ray,  wrote:

> I was using if (fd != -1) and was still getting the warning which confused
> me
> My suggestion was maybe to add the exact condition the fd analyzer is
> looking for to the warning so that folks know how to fix it/trigger
> its 'true' branch.
>
> e.g. instead of:
> "fd may not be valid"
>
> Something like this, or thereabouts:
> "fd may not be valid (expecting fd >= 0)"
>

That seems like an analyzer bug, checking for -1 should be ok. POSIX is
clear that open and socket return -1 on error. I didn't check all the other
functions that return new file descriptors, but I think they're the same.

Re: Can't build Ada

[Paul Koning via Gcc]

> On Nov 26, 2022, at 11:52 AM, Iain Sandoe  wrote:
> 
> 
> 
>> On 26 Nov 2022, at 16:42, Arnaud Charlet  wrote:
>> 
>> 
 The current statement  (https://gcc.gnu.org/install/prerequisites.html) is:
 
 GNAT
 In order to build GNAT, the Ada compiler, you need a working GNAT compiler 
 (GCC version 5.1 or later).
 
 so, if 5.1 is not working, then perhaps a PR is in order.
>>> 
>>> I will do that, if the "shell in Rosetta" thing doesn't cure the problem.
>> 
>> You won’t need to, the version of gnat you are using is recent enough, you 
>> need to follow Ian’s instructions to the letter. The Ada 2022 code is a red 
>> herring and is only problematic when you build a cross with a non matching 
>> native, not when building a native compiler.
> 
> One additional question/point - which branch are you trying to build the 
> cross from?
> 
> I am sure it will not work from upstream master.
> 
> Unfortunately, owing to lack of free time… aarch64-darwin is not yet 
> completely ready to upstream, so folks are using the development branch here: 
> https://github.com/iains/gcc-darwin-arm64 (which I will update later, based 
> on the master version mentioned earlier; if testing goes OK).
> 
> Iain.

That's the branch I'm using.

paul

Re: Can't build Ada

[Paul Koning via Gcc]

> On Nov 26, 2022, at 11:42 AM, Arnaud Charlet via Gcc  wrote:
> 
> 
>>> The current statement  (https://gcc.gnu.org/install/prerequisites.html) is:
>>> 
>>> GNAT
>>> In order to build GNAT, the Ada compiler, you need a working GNAT compiler 
>>> (GCC version 5.1 or later).
>>> 
>>> so, if 5.1 is not working, then perhaps a PR is in order.
>> 
>> I will do that, if the "shell in Rosetta" thing doesn't cure the problem.
> 
> You won’t need to, the version of gnat you are using is recent enough, you 
> need to follow Ian’s instructions to the letter. The Ada 2022 code is a red 
> herring and is only problematic when you build a cross with a non matching 
> native, not when building a native compiler.
> 
> Arno

All I can tell you is that I'm pretty sure I'm doing what Iain said, using his 
branch (up to date), and using the compilers from the Adacore open source 
release (20200818) which is GCC 8.4.1.  And once again I got that same 
complaint about Ada2020 constructs:

/usr/local/gnat/bin/gcc -c -g -O2  -gnatpg -gnata -W -Wall -nostdinc -I- 
-I. -Iada/generated -Iada -I../../../gcc-darwin/gcc/ada -Iada/libgnat 
-I../../../gcc-darwin/gcc/ada/libgnat -Iada/gcc-interface 
-I../../../gcc-darwin/gcc/ada/gcc-interface 
../../../gcc-darwin/gcc/ada/contracts.adb -o ada/contracts.o
s-imagei.ads:95:11: declare_expression is an Ada 2020 feature
s-valueu.ads:152:09: declare_expression is an Ada 2020 feature
s-valueu.ads:160:09: declare_expression is an Ada 2020 feature
s-valueu.ads:184:06: "Subprogram_Variant" is not a valid aspect identifier
s-valuei.ads:80:11: declare_expression is an Ada 2020 feature
s-valuei.ads:95:08: declare_expression is an Ada 2020 feature
s-valuei.ads:141:06: "Subprogram_Variant" is not a valid aspect identifier
s-widthu.ads:84:09: declare_expression is an Ada 2020 feature
s-widthu.ads:93:11: run-time library configuration error
s-widthu.ads:93:11: file s-imgint.ads had parser errors
s-widthu.ads:93:11: entity "System.Img_Int.Image_Integer" not available
compilation abandoned
make[2]: *** [ada/contracts.o] Error 1

paul

Re: Can't build Ada

[Iain Sandoe]

> On 26 Nov 2022, at 18:06, Paul Koning  wrote:
> 
> 
> 
>> On Nov 26, 2022, at 11:42 AM, Arnaud Charlet via Gcc  wrote:
>> 
>> 
 The current statement  (https://gcc.gnu.org/install/prerequisites.html) is:
 
 GNAT
 In order to build GNAT, the Ada compiler, you need a working GNAT compiler 
 (GCC version 5.1 or later).
 
 so, if 5.1 is not working, then perhaps a PR is in order.
>>> 
>>> I will do that, if the "shell in Rosetta" thing doesn't cure the problem.
>> 
>> You won’t need to, the version of gnat you are using is recent enough, you 
>> need to follow Ian’s instructions to the letter. The Ada 2022 code is a red 
>> herring and is only problematic when you build a cross with a non matching 
>> native, not when building a native compiler.
>> 
>> Arno
> 
> All I can tell you is that I'm pretty sure I'm doing what Iain said, using 
> his branch (up to date), and using the compilers from the Adacore open source 
> release (20200818) which is GCC 8.4.1.  And once again I got that same 
> complaint about Ada2020 constructs:
> 
> /usr/local/gnat/bin/gcc -c -g -O2  -gnatpg -gnata -W -Wall -nostdinc -I- 
> -I. -Iada/generated -Iada -I../../../gcc-darwin/gcc/ada -Iada/libgnat 
> -I../../../gcc-darwin/gcc/ada/libgnat -Iada/gcc-interface 
> -I../../../gcc-darwin/gcc/ada/gcc-interface 
> ../../../gcc-darwin/gcc/ada/contracts.adb -o ada/contracts.o
> s-imagei.ads:95:11: declare_expression is an Ada 2020 feature
> s-valueu.ads:152:09: declare_expression is an Ada 2020 feature
> s-valueu.ads:160:09: declare_expression is an Ada 2020 feature
> s-valueu.ads:184:06: "Subprogram_Variant" is not a valid aspect identifier
> s-valuei.ads:80:11: declare_expression is an Ada 2020 feature
> s-valuei.ads:95:08: declare_expression is an Ada 2020 feature
> s-valuei.ads:141:06: "Subprogram_Variant" is not a valid aspect identifier
> s-widthu.ads:84:09: declare_expression is an Ada 2020 feature
> s-widthu.ads:93:11: run-time library configuration error
> s-widthu.ads:93:11: file s-imgint.ads had parser errors
> s-widthu.ads:93:11: entity "System.Img_Int.Image_Integer" not available
> compilation abandoned
> make[2]: *** [ada/contracts.o] Error 1

1/
For the cross - you have to make sure that the newly-built “native" (Rosetta) 
compiler is found in the path first - perhaps somehow the original bootstrap 
compiler is being found (unless you installed into /usr/local .. which I tend 
to avoid)?

2/ To work around the Xcode “gotcha” of claiming gcc and g++ I find it is 
safest to be specific about CC and CXX on the command line (so 
CC=x86_64-apple-darwinNN-gcc, CXX=x86_64-apple-darwinNN-++ … )

otherwise, I can share my configure lines .. but probably best off-list.
Iain

Re: -fanalyzer: Questions on C vs CPP + use of GCC attr's like malloc()/access()

[David Malcolm via Gcc]

On Sat, 2022-11-26 at 17:47 +, Jonathan Wakely wrote:
> On Sat, 26 Nov 2022, 15:48 Gavin Ray,  wrote:
> 
> > I was using if (fd != -1) and was still getting the warning which
> > confused
> > me
> > My suggestion was maybe to add the exact condition the fd analyzer
> > is
> > looking for to the warning so that folks know how to fix it/trigger
> > its 'true' branch.
> > 
> > e.g. instead of:
> > "fd may not be valid"
> > 
> > Something like this, or thereabouts:
> > "fd may not be valid (expecting fd >= 0)"
> > 
> 
> That seems like an analyzer bug, checking for -1 should be ok. POSIX
> is
> clear that open and socket return -1 on error. I didn't check all the
> other
> functions that return new file descriptors, but I think they're the
> same.

Looking at sm-fd.cc: fd_state_machine::on_condition it looks like the
analyzer handles both checks against -1 (eq/ne) *and* checks for >= 0,
so maybe the .dot file needs updating.

Gavin, if you have a reproducer in C [1] where the wording of the
message seems "off", please can you file it in bugzilla and I'll take a
look next week.  The fd state machine is new in GCC 13, so it's
interesting to get this into the hands of end-users.

Thanks
Dave

[1] Sadly, C++ in -fanalyzer is sufficiently broken right now that it's
not worth filing extra bugs on top of the ones I already know about,
alas.

Re: Problems when building NT kernel drivers with GCC / LD

[Pali Rohár via Gcc]

On Monday 21 November 2022 08:24:36 Jan Beulich wrote:
> On 20.11.2022 14:10, Pali Rohár wrote:
> > On Saturday 05 November 2022 02:26:52 Pali Rohár wrote:
> >> On Saturday 05 November 2022 01:57:49 Pali Rohár wrote:
> >>> On Monday 31 October 2022 10:55:59 Jan Beulich wrote:
>  On 30.10.2022 02:06, Pali Rohár via Binutils wrote:
> > * GCC or LD (not sure who) sets memory alignment characteristics
> >   (IMAGE_SCN_ALIGN_MASK) into the sections of PE executable binary.
> >   These characteristics should be only in COFF object files, not
> >   executable binaries. Specially they should not be in NT kernel
> >   drivers.
> 
>  Like Martin pointed out in reply for another item, I'm pretty sure
>  this one was taken care of in bfd already (and iirc is in 2.39). You
>  fail to mention at all what versions of the various components you
>  use.
> >>>
> >>> Ou, sorry for that. I take care to write issues in all details and
> >>> totally forgot to write such important information like tool versions.
> >>>
> >>> Now I retested all issues on Debian 11 which has LD 2.35.2 and GCC
> >>> 10.2.1 and all issues are there still valid except data characteristic
> >>> IMAGE_SCN_CNT_INITIALIZED_DATA for code sections IMAGE_SCN_CNT_CODE.
> >>>
> >>> I can easily retest it with LD 2.39 and GCC 10.3.0 which is in Debian
> >>> testing.
> >>
> >> Retested with LD 2.39 and GCC 10.3.0 which is in Debian testing and
> >> following problems are additionally fixed: --exclude-all-symbols,
> >> --dynamicbase and IMAGE_SCN_ALIGN_MASK (which you mentioned above). All
> >> other still reminds.
> >>
> >> Do you need some other information?
> > 
> > Hello! I would like to ask if you need some other details or something
> > else for these issues.
> 
> Well, generally speaking it might help if you could provide smallish
> testcases for every item individually.

I have already provided simple test case - simple driver - it is linked
in the first email.

> But then, with you replying to
> me specifically, perhaps you're wrongly assuming that I would be
> planning to look into addressing any or all of these? My earlier reply
> was merely to point out that _some_ work has already been done ...

I added into CC also gcc, ld and mingw mailing list. If this is not
enough, could you tell me who to contact about those issues?

Re: [Mingw-w64-public] gcc parameter -mcrtdll= for choosing Windows C RunTime DLL library

[Pali Rohár via Gcc]

On Monday 21 November 2022 13:21:53 LIU Hao wrote:
> 在 2022/11/20 23:06, Pali Rohár 写道:
> > Thank you for explaining more details. My simple patch takes this in
> > care and defines also __MSVCRT_VERSION__ to the correct value based on
> > -mcrtdll parameter.
> 
> Apologies for reading your message only partially. I thought your patch was
> the same as MSYS2's. It turns out that you have made further progress;
> that's very kind of you.
> 
> As for the patch itself: It's probably safe to switch between MSVCR* DLLs,
> but switching from MSVCR* to UCRT requires a complete rebuild due to
> differences in implementation of stdio functions and definition of `time_t`
> on x86. There are more reasons, for example, that MSVCR80 and 90 require
> architecture-specific manifests to load, and MSVCR80 to 120 are not
> pre-installed and have to be installed by users. These could explain why
> `-mcrtdll=` hasn't gained wide use, while UCRT-based toolchains have.
> 
> So, the patch may be acceptable, but I don't think it will solve the issue
> for you. A user should usually choose MSVCRT or UCRT, which however requires
> rebuilding the CRT. For those who really really wish to link against
> MSVCR100 for example, it's always doable to pass `-nodefaultlibs` to GCC,
> and specify desired libraries explicitly.

The ultimate goal could be to improve mingw-w64 build process to compile
one set of libraries which would work with both msvcrt and ucrt. There
is already discussion about it in separate mingw-w64 email thread.
Probably not easy task, but I think it can be possible. Anyway, in any
case, this work is independent of gcc and independent of introduction of
-mcrtdll= gcc switch. So I think this switch still can be useful.

gcc-12-20221126 is now available

[GCC Administrator via Gcc]

Snapshot gcc-12-20221126 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/12-20221126/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 12 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch 
releases/gcc-12 revision a1a79572fd8a6a79693e59c1121450ed40a23be9

You'll find:

 gcc-12-20221126.tar.xz   Complete GCC

  SHA256=3a750fe86d0ecb2d39eee1d1b6b60786fb26b39c4eaa03e5875f11027c983e1f
  SHA1=8332d1b3abceae91f4a5b4bd6f6aed9e46af9451

Diffs from 12-20221119 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-12
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Re: [Mingw-w64-public] gcc parameter -mcrtdll= for choosing Windows C RunTime DLL library

[sotrdg sotrdg via Gcc]

what you want is basically a ucrt multilib. However, neither glibc provides the 
same toggle too. i do not see a good reason for your request.

Get Outlook for Android

From: Pali Rohár 
Sent: Saturday, November 26, 2022 2:09:09 PM
To: LIU Hao 
Cc: gcc@gcc.gnu.org ; mingw-w64-pub...@lists.sourceforge.net 

Subject: Re: [Mingw-w64-public] gcc parameter -mcrtdll= for choosing Windows C 
RunTime DLL library

On Monday 21 November 2022 13:21:53 LIU Hao wrote:
> 在 2022/11/20 23:06, Pali Rohár 写道:
> > Thank you for explaining more details. My simple patch takes this in
> > care and defines also __MSVCRT_VERSION__ to the correct value based on
> > -mcrtdll parameter.
>
> Apologies for reading your message only partially. I thought your patch was
> the same as MSYS2's. It turns out that you have made further progress;
> that's very kind of you.
>
> As for the patch itself: It's probably safe to switch between MSVCR* DLLs,
> but switching from MSVCR* to UCRT requires a complete rebuild due to
> differences in implementation of stdio functions and definition of `time_t`
> on x86. There are more reasons, for example, that MSVCR80 and 90 require
> architecture-specific manifests to load, and MSVCR80 to 120 are not
> pre-installed and have to be installed by users. These could explain why
> `-mcrtdll=` hasn't gained wide use, while UCRT-based toolchains have.
>
> So, the patch may be acceptable, but I don't think it will solve the issue
> for you. A user should usually choose MSVCRT or UCRT, which however requires
> rebuilding the CRT. For those who really really wish to link against
> MSVCR100 for example, it's always doable to pass `-nodefaultlibs` to GCC,
> and specify desired libraries explicitly.

The ultimate goal could be to improve mingw-w64 build process to compile
one set of libraries which would work with both msvcrt and ucrt. There
is already discussion about it in separate mingw-w64 email thread.
Probably not easy task, but I think it can be possible. Anyway, in any
case, this work is independent of gcc and independent of introduction of
-mcrtdll= gcc switch. So I think this switch still can be useful.


___
Mingw-w64-public mailing list
mingw-w64-pub...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public