Re: show size of stack needed by functions
Eric Botcazou writes: >> Output of -fstack-usage is not accurate >> === >> >> This article mentions a "call cost": >> https://mcuoneclipse.com/2015/08/21/gnu-static-stack-usage-analysis/ >> >> I checked for myself, by looking at the change of the stackpointer with a >> debugger, and, yes, there seems to be a constant mismatch (2 bytes with >> avr-gcc-5.3) between change of stack pointer and output of -fstack-usage. >> In some rare cases there are more differences, which I didn't understand >> yet. > > That's a bug, very likely in the AVR back-end, which must be fixed by someone > who knows the AVR architecture. I'll take a look. Regards Senthil
Re: Re: Re: GCC 6.1 Hard-coded C++ header paths and relocation problem on Windows
I have a vision. It is gcc/gcc/incpath.c that the problem is in. I had been looking through that file for a few days but eventually gave up. It is worth mentioning that adding an '-iprefix /this/need/not/exist' vanishes the problem. This might have something to do with the following line in incpath.c (it should be line #132 on gcc-6-branch at the moment): ``` if (iprefix && (len = cpp_GCC_INCLUDE_DIR_len) != 0) ``` Still I have no idea about how relocated paths are pulled in. I am looking forward to a patch for the relocation problem. -- Best regards, lh_mouse 2016-05-10 - 发件人：Brett Neumeier 发送日期：2016-05-10 04:31 收件人：lh_mouse 抄送：Jonathan Wakely,gcc 主题：Re: Re: GCC 6.1 Hard-coded C++ header paths and relocation problem on Windows On Tue, May 3, 2016 at 10:01 AM, lh_mouse wrote: > Should I file a bug report then? > We need some Linux testers, though not many people on Linux relocate > compilers. For what it's worth -- I encountered the same problem on a GNU/Linux system. In my specific situation, I'm cross-compiling GCC using an AMD64-to-mips64el cross-toolchain, and installing the resulting GCC in a sysroot directory. When I try to use that GCC on a target device where (of course) the sysroot directory becomes "/", the hard-coded "/path/to/sysroot" from the host system is still used to find the C++ headers, resulting in the same ".../include/c++/6.1.1/cstdlib:75:25: fatal error: stdlib.h: No such file or directory" error message you got. Changing #include_next to #include in cstdlib and cmath fixed my problem -- so, thank you very much for this discussion! It helped at least one other person. Please let me know if there's any other testing I can do to help. Cheers, Brett
Re: Re: Re: GCC 6.1 Hard-coded C++ header paths and relocation problem on Windows
We use neither --with-sysroot nor --with-build-sysroot.
The reason is that, the hard-coded path in GCC repository - that is, the
/mingw/ one - does not actually exist.
In order to build GCC for mingw targets, we take either solution:
0) Make a symlink (or rather, a copy, since Windows does not support symlinks)
as /mingw/, as mentioned in
https://sourceforge.net/p/mingw-w64/wiki2/Native%20Win64%20compiler/
1) Replace the non-existent path with an existent one, as done in
https://github.com/lhmouse/MINGW-packages/blob/master/mingw-w64-gcc-git/PKGBUILD#L112
--
Best regards,
lh_mouse
2016-05-10
-
发件人：Andrew Pinski
发送日期：2016-05-10 05:10
收件人：Brett Neumeier
抄送：lh_mouse,Jonathan Wakely,gcc
主题：Re: Re: GCC 6.1 Hard-coded C++ header paths and relocation problem on Windows
On Mon, May 9, 2016 at 1:31 PM, Brett Neumeier wrote:
> On Tue, May 3, 2016 at 10:01 AM, lh_mouse wrote:
>> Should I file a bug report then?
>> We need some Linux testers, though not many people on Linux relocate
>> compilers.
>
> For what it's worth -- I encountered the same problem on a GNU/Linux
> system. In my specific situation, I'm cross-compiling GCC using an
> AMD64-to-mips64el cross-toolchain, and installing the resulting GCC in
> a sysroot directory. When I try to use that GCC on a target device
> where (of course) the sysroot directory becomes "/", the hard-coded
> "/path/to/sysroot" from the host system is still used to find the C++
> headers, resulting in the same ".../include/c++/6.1.1/cstdlib:75:25:
> fatal error: stdlib.h: No such file or directory" error message you
> got.
>
> Changing #include_next to #include in cstdlib and cmath fixed my
> problem -- so, thank you very much for this discussion! It helped at
> least one other person.
>
> Please let me know if there's any other testing I can do to help.
This sounds like a good use of --with-build-sysroot instead of just
--with-sysroot.
I use the following for the candian cross:
--with-sysroot=/ --with-build-sysroot=${SYSROOT}
Thanks,
Andrew
>
> Cheers,
>
> Brett
Re: show size of stack needed by functions
> Output of -fstack-usage is not accurate > === > > This article mentions a "call cost": > https://mcuoneclipse.com/2015/08/21/gnu-static-stack-usage-analysis/ > > I checked for myself, by looking at the change of the stackpointer with a > debugger, and, yes, there seems to be a constant mismatch (2 bytes with > avr-gcc-5.3) between change of stack pointer and output of -fstack-usage. > In some rare cases there are more differences, which I didn't understand > yet. That's a bug, very likely in the AVR back-end, which must be fixed by someone who knows the AVR architecture. > Wishes: > - Add stack-usage in output of -fdump-ipa-cgraph, so that you don't need to > relate information from two input files at all. I guess this is not > trivial. Or is it? It's not difficult, but there is a conflict between them because -fstack-usage is designed to be conservatively correct while -fdump-ipa-cgraph is not (it does not dump the full callgraph). -- Eric Botcazou
Re: SafeStack proposal in GCC
On Mon, 9 May 2016, Michael Matz wrote: > Sure. Same QoI bug in my book. (And I'm not motivated enough to find out > if the various C standards weren't just following POSIX whe setjmp was > included, or really the other way around). Standards for setjmp and longjmp date back at least as far as the 1984 /usr/group Standard, which was a base document for the C standard library and for POSIX (and from there, they date back to at least V7 Unix). -- Joseph S. Myers jos...@codesourcery.com
Re: show size of stack needed by functions
Hi, sorry for reopening a very old thread, it took some time until I got around to write a script that parses the output of -fdump-ipa-cgraph and -fstack-usage. I'm using gcc 5.3 currently. It's mostly what I need, I get all the information about the callgraph that I wanted to get (what's inlined, which functions was taken the address of, which functions contain indirect calls). With optimization, some of these indirect calls even disappear. Nice. But there are some things that turned out not so nice, which required workarounds. Any advice what to do about them? Put them into bugzilla, each as a separate ticket? Do you think that with nowadays, it would be better (simpler, more portable to new gcc versions) to write a plugin instead of parsing these dumps? I tried with a python plugin, but the call graph information I got in form of some gimple fragments wasn't very accessible. Did I miss the right API with which everything is easy, or do you have other hints on how to get the same information as in -fdump-ipa-cgraph and -fstack-usage? TMPDIR == This one is no big problem. But maybe someone can improve the documentation on this. When you build with -flto, some of the output doesn't go into the same folder as the executable. It goes into $TMPDIR instead. Except on Windows - there it goes into GetTempPath(). So my Makefile needs to handle Windows as a special case, and use a different environment variable there (TMP instead of TMPDIR). Wishes: - Document that the output of -fstack-usage goes into TMPDIR sometimes, and document the differece on Windows. - On Windows, use GetTempPath() only as a fallback when TMPDIR is not set - Output into the same directory as the executable Output of -fstack-usage is not accurate === This article mentions a "call cost": https://mcuoneclipse.com/2015/08/21/gnu-static-stack-usage-analysis/ I checked for myself, by looking at the change of the stackpointer with a debugger, and, yes, there seems to be a constant mismatch (2 bytes with avr-gcc-5.3) between change of stack pointer and output of -fstack-usage. In some rare cases there are more differences, which I didn't understand yet. Wishes: - Document that there is a call cost not included in -fstack-usage. Document what the call cost is, for each target architecture. - Preferred: Make output of -fstack-usage accurate Symbol identifiers in output of -fstack-usage are not unique In the output of -fstack-usage, there is the name of the source file, and the name of the symbol. Unfortunately, with -flto, this is not unique. Example: static inline functions declared in header files. Usually, the stack size will be the same in all translation units (and in my project I fortunately don't have this problem currently). But there is a chance that the stack size of a function changes depending on some macro that is different for different translation units. Fixing this would have the additional benefit that my script could be simpler because it would not need to know which object file name (as given in the output of -fdump-ipa-cgraph) corresponds to which source file name (as given in the output of -fstack-usage). Wishes: - Add stack-usage in output of -fdump-ipa-cgraph, so that you don't need to relate information from two input files at all. I guess this is not trivial. Or is it? Can you, in cgraph_node::dump, simply access the stack_usage "su" of struct function *get_fun (void); and in a sufficiently late pass the values will be valid? - In -fstack-usage, use the same unique identifiers as in -fdump-ipa-cgraph. The problem with that: This fix would probably break some other tools which parse the output of -fstack-usage. I'm considering to patch gcc myself. But because of the mentioned problem, there is no big chance that this will be accepted up-stream, is there? On first glance, this isn't hard - I found this in output_stack_usage: /* We don't want to print the full qualified name because it can be long, so we strip the scope prefix, but we may need to deal with the suffix created by the compiler. */ But on second glance, I noticed that this is a suffix with a dot - not the "order" of a cgraph_node with a slash. Is it possible to access this order in output_stack_usage? Regards, Sebastian On Thu, 14 Oct 2010 00:16:29 +0200 Richard Guenther wrote: > On Wed, Oct 13, 2010 at 11:43 PM, Sebastian > wrote: > > On Wed, Oct 13, 2010 H.J. Lu wrote: > >> GCC 4.6.0 has -fstack-usage. > > Thanks. That's probably the reason I didn't find it in current manuals. > > > > On Wed, Oct 13, 2010 Ian Lance Taylor wrote: > >> The mailing list gcc@gcc.gnu.org is for the development of gcc itself. > >> This question would be more appropriate for the mailing list > >> gcc-h...@gcc.gnu.org. Please take any followups to gcc-help. Thanks. > > Since thi
Re: SafeStack proposal in GCC
Hi,
On Mon, 9 May 2016, Rich Felker wrote:
> > Done. I never understood why they left in the hugely unuseful
> > {sig,}{set,long}jmp() but removed the actually useful *context()
> > (amended somehow like above).
>
> Because those are actually part of the C language
Sure. Same QoI bug in my book. (And I'm not motivated enough to find out
if the various C standards weren't just following POSIX whe setjmp was
included, or really the other way around).
> (the non-sig versions, but the sig versions are needed to work around
> broken unices that made the non-sig versions save/restore signal mask
> and thus too slow to ever use). They're also much more useful for
> actually reasonable code (non-local exit across functions that were
> badly designed with no error paths)
Trivially obtainable with getcontext/setcontext as well.
> as opposed to just nasty hacks that
> are mostly/entirely UB anyway (coroutines, etc.).
Well, we differ in the definition of reasonable :) And I certainly don't
see any material difference in undefined behaviour between both classes of
functions. Both are "special" regarding compilers (e.g. returning
multiple times) and usage. But as the *jmp() functions can be implemented
with *context(), but not the other way around, it automatically follows
(to me!) that the latter are more useful, if for nothing else than basic
building blocks. (there are coroutine libs that try to emulate a real
makecontext with setjmp/longjmp on incapable architectures. As this is
impossible for all corner cases they are broken and generally awful on
them :) )
Ciao,
Michael.
Re: SafeStack proposal in GCC
On Mon, May 9, 2016 at 2:03 PM, Joel Sherrill wrote: > > On 5/9/2016 3:41 PM, Ian Lance Taylor wrote: >> >> On Mon, May 9, 2016 at 1:07 PM, Joel Sherrill >> wrote: >>> >>> >>> One complication on RTEMS which is a single process, multi-threaded RTOS >>> is that we can no longer check the stack bounds. For threads, we know >>> where the stack memory is and the range for each thread. For ucontext_t, >>> it seems this knowledge is unknown to the RTOS. >>> >>> Thus it would become the responsibility of the run-time using ucontext_t >>> to put in fence patterns and check those. >> >> >> On RTEMS and similar systems, you could write makecontext to register >> the stack (whose start and length are known to the function) with the >> RTOS. > > > Ahh... slow today. swapcontext() would have to work with the stack > checker. > Interesting.. the stack usage reporting would have to be taught > about the ucontext_t's in the system and report those as well. > > Am I missing something or is there no way to know when a context > goes out of existence in the API? That is correct. Good point. Ian
Re: Re: GCC 6.1 Hard-coded C++ header paths and relocation problem on Windows
On Mon, May 9, 2016 at 1:31 PM, Brett Neumeier wrote:
> On Tue, May 3, 2016 at 10:01 AM, lh_mouse wrote:
>> Should I file a bug report then?
>> We need some Linux testers, though not many people on Linux relocate
>> compilers.
>
> For what it's worth -- I encountered the same problem on a GNU/Linux
> system. In my specific situation, I'm cross-compiling GCC using an
> AMD64-to-mips64el cross-toolchain, and installing the resulting GCC in
> a sysroot directory. When I try to use that GCC on a target device
> where (of course) the sysroot directory becomes "/", the hard-coded
> "/path/to/sysroot" from the host system is still used to find the C++
> headers, resulting in the same ".../include/c++/6.1.1/cstdlib:75:25:
> fatal error: stdlib.h: No such file or directory" error message you
> got.
>
> Changing #include_next to #include in cstdlib and cmath fixed my
> problem -- so, thank you very much for this discussion! It helped at
> least one other person.
>
> Please let me know if there's any other testing I can do to help.
This sounds like a good use of --with-build-sysroot instead of just
--with-sysroot.
I use the following for the candian cross:
--with-sysroot=/ --with-build-sysroot=${SYSROOT}
Thanks,
Andrew
>
> Cheers,
>
> Brett
Re: Machine constraints list
On Mon, 9 May 2016, David Wohlferd wrote: > In my defense, I can't find any official list of which are 'tertiary' and > which are deprecated (https://gcc.gnu.org/ml/gcc/2016-03/msg00010.html). Deprecated targets are exactly those in the "# Obsolete configurations." list in config.gcc (targets requiring --enable-obsolete to build them). The only architecture for which all configurations are currently deprecated is mep. Of course, such deprecated targets should still have all their documentation present, bug reports kept open, etc. - it's only when support for a target is actually removed from GCC that documentation etc. is removed and bug reports closed (as WONTFIX). -- Joseph S. Myers jos...@codesourcery.com
Re: SafeStack proposal in GCC
On 5/9/2016 3:41 PM, Ian Lance Taylor wrote: On Mon, May 9, 2016 at 1:07 PM, Joel Sherrill wrote: One complication on RTEMS which is a single process, multi-threaded RTOS is that we can no longer check the stack bounds. For threads, we know where the stack memory is and the range for each thread. For ucontext_t, it seems this knowledge is unknown to the RTOS. Thus it would become the responsibility of the run-time using ucontext_t to put in fence patterns and check those. On RTEMS and similar systems, you could write makecontext to register the stack (whose start and length are known to the function) with the RTOS. Ahh... slow today. swapcontext() would have to work with the stack checker. Interesting.. the stack usage reporting would have to be taught about the ucontext_t's in the system and report those as well. Am I missing something or is there no way to know when a context goes out of existence in the API? Ian --joel
Re: Machine constraints list
On 5/9/2016 6:42 AM, paul_kon...@dell.com wrote: On May 8, 2016, at 6:27 PM, David Wohlferd wrote: If these architectures aren't supported anymore, is it time to drop some of these from this page? Your theory is quite mistaken. A lot of the ones you labeled "drop" are supported. Quite possibly all of them. Ok, I see that. Spot checking some of the architectures, they are still getting periodic checkins. In my defense, I can't find any official list of which are 'tertiary' and which are deprecated (https://gcc.gnu.org/ml/gcc/2016-03/msg00010.html). That said, there are still a lot of entries on that machine constraint page. How about if I re-organize the list similar to function attributes (https://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html)? Or at a minimum, add @anchors for each architecture so there are links? dw
Re: SafeStack proposal in GCC
On Mon, May 09, 2016 at 10:03:02PM +0200, Michael Matz wrote:
> Hi,
>
> On Mon, 9 May 2016, Rich Felker wrote:
>
> > > > The *context APIs are deprecated and I'm not sure they're worth
> > > > supporting with this. It would be a good excuse to get people to
> > > > stop using them.
> > >
> > > How? POSIX decided to remove the facilities without any adequate
> > > replacement (thread aren't).
> >
> > Threads work just as well as the ucontext api for coroutines. Due to the
> > requirement to save/restore signal masks, the latter requires a syscall,
> > making it no faster than a voluntary context switch via futex syscall.
>
> Uhm, no. If you disregard efficiency, sure, POSIX threads are sometimes a
> replacement on some platforms. They still have completely different
> activation models (being synchronous with *context, for which you need
> even further slow synchronization in a threading model).
switch_to_next:
sem_post(next->sem);
while (sem_wait(self->sem));
It can actually be done more idiomatically with cond vars, but I don't
see a way to make it as efficient.
> > Most of the other hacks people used the ucontext API for were complete
> > hacks with undefined behavior, anyway.
>
> Sure, that doesn't imply the facility should be removed. I can misuse all
> kinds of stuff.
Indeed.
> > BTW it's not even possible to implement makecontext on most targets due
> > to the wacky variadic calling convention it uses -- in most ABIs,
> > there's simply no way to shift the variadic args into the right slots
> > for calling the start function for the new context without knowing their
> > types, and the implementation has no way to know the types. So it's
> > really an unusably broken API.
>
> Of course. But _that_ implies that a workable replacement should have
> been put in place, not the unrealistic stance POSIX took with the removal:
> makecontext2(ucontext_t *ucp, void (*func)(void*), void* cookie);
It could have been done even more simply, without a new function, by
just saying the behavior is undefined unless func has type
void(*)(void), argc==1, and the first variadic arg has type void*.
> Done. I never understood why they left in the hugely
> unuseful {sig,}{set,long}jmp() but removed the actually useful *context()
> (amended somehow like above).
Because those are actually part of the C language (the non-sig
versions, but the sig versions are needed to work around broken unices
that made the non-sig versions save/restore signal mask and thus too
slow to ever use). They're also much more useful for actually
reasonable code (non-local exit across functions that were badly
designed with no error paths) as opposed to just nasty hacks that are
mostly/entirely UB anyway (coroutines, etc.).
Rich
Re: SafeStack proposal in GCC
On Mon, May 9, 2016 at 1:07 PM, Joel Sherrill wrote: > > One complication on RTEMS which is a single process, multi-threaded RTOS > is that we can no longer check the stack bounds. For threads, we know > where the stack memory is and the range for each thread. For ucontext_t, > it seems this knowledge is unknown to the RTOS. > > Thus it would become the responsibility of the run-time using ucontext_t > to put in fence patterns and check those. On RTEMS and similar systems, you could write makecontext to register the stack (whose start and length are known to the function) with the RTOS. Ian
Re: Re: GCC 6.1 Hard-coded C++ header paths and relocation problem on Windows
On Tue, May 3, 2016 at 10:01 AM, lh_mouse wrote: > Should I file a bug report then? > We need some Linux testers, though not many people on Linux relocate > compilers. For what it's worth -- I encountered the same problem on a GNU/Linux system. In my specific situation, I'm cross-compiling GCC using an AMD64-to-mips64el cross-toolchain, and installing the resulting GCC in a sysroot directory. When I try to use that GCC on a target device where (of course) the sysroot directory becomes "/", the hard-coded "/path/to/sysroot" from the host system is still used to find the C++ headers, resulting in the same ".../include/c++/6.1.1/cstdlib:75:25: fatal error: stdlib.h: No such file or directory" error message you got. Changing #include_next to #include in cstdlib and cmath fixed my problem -- so, thank you very much for this discussion! It helped at least one other person. Please let me know if there's any other testing I can do to help. Cheers, Brett
Re: SafeStack proposal in GCC
On 5/9/2016 3:03 PM, Michael Matz wrote:
Hi,
On Mon, 9 May 2016, Rich Felker wrote:
The *context APIs are deprecated and I'm not sure they're worth
supporting with this. It would be a good excuse to get people to
stop using them.
How? POSIX decided to remove the facilities without any adequate
replacement (thread aren't).
Threads work just as well as the ucontext api for coroutines. Due to the
requirement to save/restore signal masks, the latter requires a syscall,
making it no faster than a voluntary context switch via futex syscall.
Uhm, no. If you disregard efficiency, sure, POSIX threads are sometimes a
replacement on some platforms. They still have completely different
activation models (being synchronous with *context, for which you need
even further slow synchronization in a threading model).
One complication on RTEMS which is a single process, multi-threaded RTOS
is that we can no longer check the stack bounds. For threads, we know
where the stack memory is and the range for each thread. For ucontext_t,
it seems this knowledge is unknown to the RTOS.
Thus it would become the responsibility of the run-time using ucontext_t
to put in fence patterns and check those.
Most of the other hacks people used the ucontext API for were complete
hacks with undefined behavior, anyway.
Sure, that doesn't imply the facility should be removed. I can misuse all
kinds of stuff.
BTW it's not even possible to implement makecontext on most targets due
to the wacky variadic calling convention it uses -- in most ABIs,
there's simply no way to shift the variadic args into the right slots
for calling the start function for the new context without knowing their
types, and the implementation has no way to know the types. So it's
really an unusably broken API.
Of course. But _that_ implies that a workable replacement should have
been put in place, not the unrealistic stance POSIX took with the removal:
makecontext2(ucontext_t *ucp, void (*func)(void*), void* cookie);
Done. I never understood why they left in the hugely
unuseful {sig,}{set,long}jmp() but removed the actually useful *context()
(amended somehow like above).
Ciao,
Michael.
--joel
Re: SafeStack proposal in GCC
On 5/9/2016 2:45 PM, Ian Lance Taylor wrote: On Mon, May 9, 2016 at 12:41 PM, Joel Sherrill wrote: On 5/9/2016 2:25 PM, Ian Lance Taylor wrote: On Fri, May 6, 2016 at 10:42 PM, Rich Felker wrote: The *context APIs are deprecated and I'm not sure they're worth supporting with this. It would be a good excuse to get people to stop using them. The gccgo library uses them, because there is no working alternative. FWIW when this transition occurred, that's when the RTEMS port broke. We don't have these methods. Yes, that was unfortunate, but it was a significant increase in efficiency. It would be an interesting exercise to see if they could be implemented in terms of our internal thread context management APIs but no one has ever looked into it deeply. They are short functions, and easy to implement. They don't need to use any thread context management, they just manipulate registers. The catch is that, because they manipulate registers, they are inherently machine-specific. I suppose we could reuse implementations from *BSD for a subset of targets. Those would likely be the targets folks care about anyway. Hmm... would those make sense to add to newlib? I am thinking they are similar to setjmp/longjmp and shouldn't need supervisor mode access. Ian
Re: SafeStack proposal in GCC
Hi,
On Mon, 9 May 2016, Rich Felker wrote:
> > > The *context APIs are deprecated and I'm not sure they're worth
> > > supporting with this. It would be a good excuse to get people to
> > > stop using them.
> >
> > How? POSIX decided to remove the facilities without any adequate
> > replacement (thread aren't).
>
> Threads work just as well as the ucontext api for coroutines. Due to the
> requirement to save/restore signal masks, the latter requires a syscall,
> making it no faster than a voluntary context switch via futex syscall.
Uhm, no. If you disregard efficiency, sure, POSIX threads are sometimes a
replacement on some platforms. They still have completely different
activation models (being synchronous with *context, for which you need
even further slow synchronization in a threading model).
> Most of the other hacks people used the ucontext API for were complete
> hacks with undefined behavior, anyway.
Sure, that doesn't imply the facility should be removed. I can misuse all
kinds of stuff.
> BTW it's not even possible to implement makecontext on most targets due
> to the wacky variadic calling convention it uses -- in most ABIs,
> there's simply no way to shift the variadic args into the right slots
> for calling the start function for the new context without knowing their
> types, and the implementation has no way to know the types. So it's
> really an unusably broken API.
Of course. But _that_ implies that a workable replacement should have
been put in place, not the unrealistic stance POSIX took with the removal:
makecontext2(ucontext_t *ucp, void (*func)(void*), void* cookie);
Done. I never understood why they left in the hugely
unuseful {sig,}{set,long}jmp() but removed the actually useful *context()
(amended somehow like above).
Ciao,
Michael.
Re: SafeStack proposal in GCC
On Mon, May 9, 2016 at 12:48 PM, Joel Sherrill wrote: > > On 5/9/2016 2:45 PM, Ian Lance Taylor wrote: >> >> On Mon, May 9, 2016 at 12:41 PM, Joel Sherrill >> wrote: >>> >>> >>> On 5/9/2016 2:25 PM, Ian Lance Taylor wrote: On Fri, May 6, 2016 at 10:42 PM, Rich Felker wrote: > > > > The *context APIs are deprecated and I'm not sure they're worth > supporting with this. It would be a good excuse to get people to stop > using them. The gccgo library uses them, because there is no working alternative. >>> >>> >>> >>> FWIW when this transition occurred, that's when the RTEMS port broke. >>> We don't have these methods. >> >> >> Yes, that was unfortunate, but it was a significant increase in >> efficiency. >> >>> It would be an interesting exercise to see if they could be >>> implemented in terms of our internal thread context management >>> APIs but no one has ever looked into it deeply. >> >> >> They are short functions, and easy to implement. They don't need to >> use any thread context management, they just manipulate registers. >> The catch is that, because they manipulate registers, they are >> inherently machine-specific. > > > I suppose we could reuse implementations from *BSD for a subset > of targets. Those would likely be the targets folks care about > anyway. > > Hmm... would those make sense to add to newlib? I am thinking > they are similar to setjmp/longjmp and shouldn't need supervisor > mode access. Makes sense to me. Ian
Re: SafeStack proposal in GCC
On Mon, May 9, 2016 at 12:41 PM, Joel Sherrill wrote: > > On 5/9/2016 2:25 PM, Ian Lance Taylor wrote: >> >> On Fri, May 6, 2016 at 10:42 PM, Rich Felker wrote: >>> >>> >>> The *context APIs are deprecated and I'm not sure they're worth >>> supporting with this. It would be a good excuse to get people to stop >>> using them. >> >> >> The gccgo library uses them, because there is no working alternative. > > > FWIW when this transition occurred, that's when the RTEMS port broke. > We don't have these methods. Yes, that was unfortunate, but it was a significant increase in efficiency. > It would be an interesting exercise to see if they could be > implemented in terms of our internal thread context management > APIs but no one has ever looked into it deeply. They are short functions, and easy to implement. They don't need to use any thread context management, they just manipulate registers. The catch is that, because they manipulate registers, they are inherently machine-specific. Ian
Re: SafeStack proposal in GCC
On Mon, May 9, 2016 at 12:35 PM, Rich Felker wrote: > On Mon, May 09, 2016 at 09:02:33PM +0200, Michael Matz wrote: >> Hi, >> >> On Sat, 7 May 2016, Rich Felker wrote: >> >> > > > * sigaltstack and swapcontext are broken too. >> > > >> > > We have prototype that supports swapcontext that we're happy to >> > > release, but it clearly requires more work before being ready to merge >> > > upstream. >> > >> > The *context APIs are deprecated and I'm not sure they're worth >> > supporting with this. It would be a good excuse to get people to stop >> > using them. >> >> How? POSIX decided to remove the facilities without any adequate >> replacement (thread aren't). > > Threads work just as well as the ucontext api for coroutines. Due to > the requirement to save/restore signal masks, the latter requires a > syscall, making it no faster than a voluntary context switch via > futex syscall. No, threads do not work as well. You can not ignore efficiency considerations. Coroutine switching is much faster with setcontext, even though it does a system call. > Most of the other hacks people used the ucontext API for were complete > hacks with undefined behavior, anyway. And yet code like gccgo's library works, on many different systems. > BTW it's not even possible to implement makecontext on most targets > due to the wacky variadic calling convention it uses -- in most ABIs, > there's simply no way to shift the variadic args into the right slots > for calling the start function for the new context without knowing > their types, and the implementation has no way to know the types. So > it's really an unusably broken API. I certainly agree that makecontext is broken by design. But it is easy enough, and safe, to use makecontext with functions that take no arguments. I would fully support an effort to propagate a replacement for makecontext that can actually work more generally. I think the current approach of simply dropping support is unwise. Ian
Re: SafeStack proposal in GCC
On 5/9/2016 2:25 PM, Ian Lance Taylor wrote: On Fri, May 6, 2016 at 10:42 PM, Rich Felker wrote: The *context APIs are deprecated and I'm not sure they're worth supporting with this. It would be a good excuse to get people to stop using them. The gccgo library uses them, because there is no working alternative. FWIW when this transition occurred, that's when the RTEMS port broke. We don't have these methods. It would be an interesting exercise to see if they could be implemented in terms of our internal thread context management APIs but no one has ever looked into it deeply. In general coroutine support requires the ability to designate some area of memory as stack space. Ian --joel
Re: CppCoreGuidelines warnings
On Mon, May 9, 2016 at 5:18 AM, Jonathan Wakely wrote: > On 8 May 2016 at 02:10, Christopher Di Bella wrote: >> Hi all, >> >> I've been tracking gcc-digest for a bit, but would like to be a little >> more involved in the development of gcc. >> >> I haven't been able to find anything about the CppCoreGuidelines in >> gcc -- I'm wondering if there's a warning system in the pipeline that >> I might have missed in the digest thread? If so, great, who do I need >> to contact about helping out? >> >> If not, I'd like to get a start on implementing a warning system for >> them. I'll create a branch, but I doubt it'll be ready for gcc 7.1's >> release. > > Hi, I don't think anyone is working on that yet. > > See https://gcc.gnu.org/contribute.html for some prerequisites to > contributing significant changes to GCC. > > I don't know the status of the static analysis tool the Microsoft were > planning to release, which would do a lot of the checking. To > incorporate the checks into GCC would probably involve changes to both > the C++ front-end and the C++ library, but I would welcome such > changes. As would I. You can coordinate with me about front end changes. Thanks, Jason
Re: SafeStack proposal in GCC
On Mon, May 09, 2016 at 09:02:33PM +0200, Michael Matz wrote: > Hi, > > On Sat, 7 May 2016, Rich Felker wrote: > > > > > * sigaltstack and swapcontext are broken too. > > > > > > We have prototype that supports swapcontext that we're happy to > > > release, but it clearly requires more work before being ready to merge > > > upstream. > > > > The *context APIs are deprecated and I'm not sure they're worth > > supporting with this. It would be a good excuse to get people to stop > > using them. > > How? POSIX decided to remove the facilities without any adequate > replacement (thread aren't). Threads work just as well as the ucontext api for coroutines. Due to the requirement to save/restore signal masks, the latter requires a syscall, making it no faster than a voluntary context switch via futex syscall. Most of the other hacks people used the ucontext API for were complete hacks with undefined behavior, anyway. BTW it's not even possible to implement makecontext on most targets due to the wacky variadic calling convention it uses -- in most ABIs, there's simply no way to shift the variadic args into the right slots for calling the start function for the new context without knowing their types, and the implementation has no way to know the types. So it's really an unusably broken API. Rich
Re: SafeStack proposal in GCC
On Fri, May 6, 2016 at 10:42 PM, Rich Felker wrote: > > The *context APIs are deprecated and I'm not sure they're worth > supporting with this. It would be a good excuse to get people to stop > using them. The gccgo library uses them, because there is no working alternative. In general coroutine support requires the ability to designate some area of memory as stack space. Ian
Re: SafeStack proposal in GCC
Hi, On Sat, 7 May 2016, Rich Felker wrote: > > > * sigaltstack and swapcontext are broken too. > > > > We have prototype that supports swapcontext that we're happy to > > release, but it clearly requires more work before being ready to merge > > upstream. > > The *context APIs are deprecated and I'm not sure they're worth > supporting with this. It would be a good excuse to get people to stop > using them. How? POSIX decided to remove the facilities without any adequate replacement (thread aren't). Ciao, Michael.
Re: (R5900) Implementing Vector Support
On 05/06/2016 09:28 PM, Woon yung Liu wrote: Regarding multiplication of vectors, is there a way to work with a multiplication operation that results in something like this (the result is spread across these 3 registers), without re-ordering any elements: RD: A6xB6, A4xB4, A2xB2, A0xA0 LO: A7xB7, A6xB6, A3xB3, A2xA2 HI: A5xB5, A4xB4, A1xB1, A0xA0 A0-A7 and B0-B7 are the 8 elements of two V8HI vectors, which are multiplied together to produce a widened multiplication result. It looks like the vector hi/lo multiplication pattern would work with the values in HI and LO, but the order of the elements don't seem to be in a way that GCC expects. Assuming that it is possible to put this pattern to use, does GCC allow the vec_widen_smult_hi and vec_widen_smult_lo patterns to be combined together? Like for the divmod (division + modulus) patterns. The instruction described above (PMULTH) will result in calculation of both the hi and lo parts of the result, in one instruction. Hence combining the two patterns would be more efficient. You can use this if you reshuffle the results. Since it appears that PMULTH naturally produces even results in RD, it would seem to make the most sense to attempt to construct the odd results from LO+HI. However, I don't see anything in the TX79 isa that's particularly helpful there. That said, pmulth r0, x, y pmflo t1 pmfhi t2 pcpyld r1, t1, t2 pcpyud r2, t2, t1 would appear to produce the results gcc expects for the hi/lo multiples. Don't worry overmuch about initially generating two copies of the pmulth instruction. We have a similar problem with the ia64 patterns. Rely on the rtl CSE pass to remove the duplicate instructions. r~
Re: Bug maintenance
On 08/05/16 23:13, Oleg Endo wrote: There are nearly 10,000 still unresolved bugs in Bugzilla, almost half of which are New, and a third Unconfirmed, so I'm sure any effort to help reduce the number is of value and appreciated. That's exactly what prompted me to ask. There's such a vast number of them, it's hard to believe that 9 year old bugs are still of interest. Sometimes there is. Before randomly closing any bugs because they are too old, one should@least have a look@them and see if they're still an issue etc. Often things would've been fixed along the way, but not all of them. There are some 10-years old bugs that have a very clear description of what needs to be done to fix them, it is just that no one has had time to do it yet. Others don't have a clear fix, but there is a lot of info about things tried but failed. Losing all that info would be bad. My humble opinion is that going through the list from old to new is not the most useful or efficient way to contribute to GCC (if it is the only way you want to contribute, then please go ahead, it is still useful). Old bugs do not hurt anyone except perhaps when searching for duplicates. In that case, it may be worth spending a few minutes checking if it is fixed already, ask the submitter for more info, or confirm it if UNCONFIRMED and updating the description so one can see clearly that it is not a duplicate. Triaging old bugs (except for fixing them) is not the most useful: users may have simply forgotten all about it or not be able to reproduce it anymore or moved on and not care... On the other hand, it is rather more useful to start with recent bugs, which are more likely to be relevant, and confirm them, ask for more info, find oldest duplicate with more info, or classify them under various meta-bugs. Rather than seeing Bugzilla as a TODO list for devs, it is rather more precise to see it as a knowledge database about bugs. Cheers, Manuel.
GSOC '16 student | Ayush Goel
Hey, I wanted to introduce myself to the gcc’s developer's community. I have been selected for the google summer of code program with gcc for 2016. The title of my project is - Replace libiberty with gnulib I’ve created a very short wiki describing the project and my initial approach at how I’ll be proceeding. https://gcc.gnu.org/wiki/replacelibibertywithgnulib Any kind of suggestion or criticism to the approach mentioned will be highly appreciated. It’s a pleasure working with gcc. - Cheers Ayush Goel
Re: Machine constraints list
> On May 8, 2016, at 6:27 PM, David Wohlferd wrote: > > Looking at the v6 release criteria (https://gcc.gnu.org/gcc-6/criteria.html) > there are about a dozen supported platforms. > > Looking at the Machine Constraints docs > (https://gcc.gnu.org/onlinedocs/gcc/Machine-Constraints.html), there are 34 > architectures listed. That's a lot of entries to scroll thru. If these > architectures aren't supported anymore, is it time to drop some of these from > this page? > > As a first pass, maybe something like this: > > Keep > AArch64 family—config/aarch64/constraints.md > ARM family—config/arm/constraints.md > MIPS—config/mips/constraints.md > PowerPC and IBM RS6000—config/rs6000/constraints.md > S/390 and zSeries—config/s390/s390.h > SPARC—config/sparc/sparc.h > x86 family—config/i386/constraints.md > > Drop > ... Your theory is quite mistaken. A lot of the ones you labeled "drop" are supported. Quite possibly all of them. paul
Re: Bug maintenance
On 05/08/2016 04:13 PM, Oleg Endo wrote: Sometimes there is. Before randomly closing any bugs because they are too old, one should at least have a look at them and see if they're still an issue etc. Often things would've been fixed along the way, but not all of them. When this is the case I do try to git bisect the issue so that I can confidently say the issue is fixed rather than just latent. Of course that dramatically increases the amount of time necessary to squash out any issue that seems to be working correctly on the trunk. jeff
Re: Bug maintenance
On 05/08/2016 04:03 PM, David Wohlferd wrote: On 4/28/2016 9:41 AM, Martin Sebor wrote: On 04/28/2016 01:35 AM, David Wohlferd wrote: As part of the work I've done on inline asm, I've been looking thru the bugs for it. There appear to be a number that have been fixed or overtaken by events over the years, but the bug is still open. Is closing some of these old bugs of any value? If so, how do I pursue this? There are nearly 10,000 still unresolved bugs in Bugzilla, almost half of which are New, and a third Unconfirmed, so I'm sure any effort to help reduce the number is of value and appreciated. That's exactly what prompted me to ask. There's such a vast number of them, it's hard to believe that 9 year old bugs are still of interest. I consistently fix a few of these for every release, as do other developers. They're all still of interest, though regressions certainly get the most attention. I do think the backlog is too large and needs a good cleanout and will encourage anyone with an interest to do whatever they can to flush out old bugs. jeff
Re: CppCoreGuidelines warnings
On 8 May 2016 at 02:10, Christopher Di Bella wrote: > Hi all, > > I've been tracking gcc-digest for a bit, but would like to be a little > more involved in the development of gcc. > > I haven't been able to find anything about the CppCoreGuidelines in > gcc -- I'm wondering if there's a warning system in the pipeline that > I might have missed in the digest thread? If so, great, who do I need > to contact about helping out? > > If not, I'd like to get a start on implementing a warning system for > them. I'll create a branch, but I doubt it'll be ready for gcc 7.1's > release. Hi, I don't think anyone is working on that yet. See https://gcc.gnu.org/contribute.html for some prerequisites to contributing significant changes to GCC. I don't know the status of the static analysis tool the Microsoft were planning to release, which would do a lot of the checking. To incorporate the checks into GCC would probably involve changes to both the C++ front-end and the C++ library, but I would welcome such changes.
