Re: Can GCC generate totally native Microsoft Windows binaries as Visual Studio?
On 2018/1/5 15:30, timofonic timofonic wrote: > Hello. > > Excuse me my ignorance, but that's what people say me. > > GCC can compile to Microsoft Windows platforms, I understand it. But > people say me it uses a "shim" between *nix and native Microsoft > Windows API. > There are three platforms on Windows: Cygwin, the original mingw32, and mingw-w64. It is only Cygwin that relies on the emulation layer. mingw32 and mingw-w64 both make use of system DLLs directly, at the cost of absence of quite a little infrastructure mandated by POSIX (e.g. signals other than those in standard C, the fork syscall, terminal support, filesystem, etc). Programs that require no such support (by having some features disabled or worked around) should work fine. > Some developers said me GCC on Windows is a "toy compiler". > > Is this right? > Over-subjective opinions like that are often initiation of *worthless* wars. You learn *nothing* from the answer. Judge wisely. > Kind regards. > -- Best regards, LH_Mouse
Re: [question] replacing called function by gimple_call_set_fndecl doesn't actually take effect
On Fri, Jan 5, 2018 at 5:57 AM, Tong Zhou wrote:
> Hi,
>
> I am new to gcc and was trying to implement a gimple pass today. One thing
> I tried to do was to make a call_stat that originally calls malloc call
> another function like new_malloc. I used gimple_call_set_fndecl and also
> did update_stmt (although I don't know exactly what it does). But the final
> assembly code still calls the old function. The relevant code is as follows:
>
>
> tree malloc_fn_type
> = build_function_type_list (void_type_node, size_type_node,
> NULL_TREE);
> tree new_malloc = build_fn_decl("new_malloc", malloc_fn_type);
>
> struct cgraph_node *alloc_node = my_get_malloc_node();
> struct cgraph_edge *edge = NULL;
> struct cgraph_node *caller = NULL;
>
> for (edge = alloc_node->callers; edge; edge = edge->next_caller)
> {
> gimple callStmt = edge->call_stmt;
> gimple_call_set_fndecl(callStmt, new_malloc);
> update_stmt (callStmt);
> }
>
>
> The callee was indeed the new_malloc when I use debug_gimple_stmt to print
> the call_stmt out, but the generated assembly code or dumped gimble file
> still use the old malloc. Thanks in advance!
I would guess the cgraph is stale at the point you modify it (the
edge->call_stmt).
This part of the callgraph isn't really kept up-to-date.
Richard.
> Thanks,
> Tong
Re: GCC and Meltdown and Spectre vulnerabilities
On 1/4/18, Will Hawkins wrote: > On Thu, Jan 4, 2018 at 10:10 PM, Eric Gallager > wrote: >> Is there anything GCC could be doing at the compiler level to mitigate >> the recently-announced Meltdown and Spectre vulnerabilities? From >> reading about them, it seems like they involve speculative execution >> and indirect branch prediction, and those are the domain of things the >> compiler deals with, right? (For reference, Meltdown is CVE-2017-5754, >> and Spectre is CVE-2017-5753 and CVE-2017-5715) >> >> Just wondering, >> Eric > > Check out > > https://support.google.com/faqs/answer/7625886 > > and especially > > http://git.infradead.org/users/dwmw2/gcc-retpoline.git/shortlog/refs/heads/gcc-7_2_0-retpoline-20171219 > > I'd love to hear what other people have heard! > > Will > Thanks, this is what I was looking for. Seeing commits by H.J. Lu in that branch gives me confidence that it'll eventually make it back into trunk. Eric
Re: GCC and Meltdown and Spectre vulnerabilities
On 1/5/18, Eric Gallager wrote:
> On 1/4/18, Will Hawkins wrote:
>> On Thu, Jan 4, 2018 at 10:10 PM, Eric Gallager
>> wrote:
>>> Is there anything GCC could be doing at the compiler level to mitigate
>>> the recently-announced Meltdown and Spectre vulnerabilities? From
>>> reading about them, it seems like they involve speculative execution
>>> and indirect branch prediction, and those are the domain of things the
>>> compiler deals with, right? (For reference, Meltdown is CVE-2017-5754,
>>> and Spectre is CVE-2017-5753 and CVE-2017-5715)
>>>
>>> Just wondering,
>>> Eric
>>
>> Check out
>>
>> https://support.google.com/faqs/answer/7625886
>>
>> and especially
>>
>> http://git.infradead.org/users/dwmw2/gcc-retpoline.git/shortlog/refs/heads/gcc-7_2_0-retpoline-20171219
>>
>> I'd love to hear what other people have heard!
>>
>> Will
>>
>
> Thanks, this is what I was looking for. Seeing commits by H.J. Lu in
> that branch gives me confidence that it'll eventually make it back
> into trunk.
>
> Eric
>
Oh, and apparently there was already a thread on gcc-patches relevant
to this as of yesterday that I missed; it's here:
https://gcc.gnu.org/ml/gcc-patches/2018-01/msg00205.html ("[PATCH 0/3]
Add __builtin_load_no_speculate")
Re: GCC and Meltdown and Spectre vulnerabilities
* timofonic timofonic: > Paranoid jails/sandboxes inside a virtual machine may mitigate a lot > the risk for those untrusted binaries, right? Someone needs to impelement those sandboxes and virtual machines, and GCC changes may help with writing them in such a way that they are less exposed to these vulnerabilities. (I'm not sure if this is the right way forward—I'm just trying to explain the rationale for potential GCC changes.)
