Fix gcc warnings during mono linux-x64 build

[am11]

main with Debug configuration: 822 warnings - http://sprunge.us/2GzrDE
PR with Debug configuration: 3 warnings related to deprecated sys/sysctl.h includes - http://sprunge.us/JuyA3K

after fixing Debug warnings, there were 13 additional warnings in Release configuration:
http://sprunge.us/PJCivP

PR with Release configuration: (same) 3 warnings - http://sprunge.us/NwKHNE

Used:

• same docker image used in CI for coreclr gcc build: mcr.microsoft.com/dotnet-buildtools/prereqs:debian-11-gcc11-amd64-20210916125744-f42d766
• build command: runtime/build.sh mono -gcc -c Debug (and later with -c Release)

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this PR. If you have write-permissions please help me learn by adding exactly one area label.

[lambdageek]

Mostly LGTM.

1. @lateralusX should take a look at the EP changes
2. I don't understand the change from MAX_SYMBOL_SIZE to 1024 in emit_info_symbol
3. For the components it would be better to rename the global symbols with prefixes&suffixes and add a comment to not use them directly.

[am11]

@lambdageek, I have reverted files which are pulled in by #60725 and #60726.

It would be great to have a gcc leg for mono in CI as well to preserve the build status from regressing. Separate leg or as a step to the existing:

(mono build with gcc; ./build.sh mono -gcc takes < 2 mins..)

cc @akoeplinger

[akoeplinger]

Thanks, found one thing to address and one question but looks good otherwise :)

[akoeplinger]

this is no longer used because this code from mono/mono was undefined in ENABLE_NETCORE and removed in dotnet/runtime: https://github.com/mono/mono/blob/8b3b6666a858e02137b192c923727bcfd00ef620/mono/mini/debugger-agent.c#L2873-L2876

@lambdageek @vargaz do you know if that is intentional, i.e. do we no longer need to suspend creating threadpool threads? or is this just something that was missed while porting to dotnet/runtime now that the threadpool works differently?

[lambdageek]

Maybe @vargaz remembers. I think we don't need it anymore - the old threadpool had a native Monitor thread that was responsible for monitoring workers. So the debugger stopped all the managed worker threads, but it didn't have any idea about the monitor thread. In netcore, we don't have a native monitor thread - everything is done by managed threads. So when the debugger suspends the runtime, it will suspend the thread pool worker creation, too.

[akoeplinger]

Ok sounds good then :)

[akoeplinger]

Awesome ❤️