Hi On 10/17, Richard Biener wrote: > On Wed, Oct 16, 2019 at 7:46 PM Giuliano Belinassi > <giuliano.belina...@usp.br> wrote: > > > > Hi, > > > > Previously, the lto-wrapper communicates with ld by creating a pipe from > > lto-wrapper's stdout to ld's stdin. This patch uses a temporary file for > > this communication, releasing stdout to be used for debugging. > > I'm not sure it is a good idea on its own.
The issue is that debugging a gcc python plugin in LTO mode using pdb, the pdb output will be redirected to ld. As a consequence, no messages from pdb will be displayed and lto will crash, as we discussed in IRC. Sure, one can use another python debugger such as wdb, as suggested in IRC, but it seems really fragile that python stdout gets mixed with lto1 stdout. The point of this patch is to fix this issue, since using stdout seems fragile based on this information, as discussed in IRC. > Then you have to consider that > the lto-plugin is used to drive different GCC versions (and thus lto-wrappers) > and you are breaking compatibility with older versions which makes it > really not an option. I didn't know about that, but I could address that considering that there are two cases: (1) lto-plugin is outdated (2) lto-wrapper is outdated In (1), we have no issue at all because lto-wrapper will be launched without the --to_ld_list and thus lto-wrapper will fallback to stdout, even if lto-wrapper is patched. If it is not, since it won't receive this parameter at all, everything will work as before. In (2), we have the problem that if lto-wrapper is present, it won't understand the --to_ld_list parameter and it will crash. Therefore I could patch lto-wrapper to have the following behaviour: lto-wrapper will accept an extra parameter, say `--support-file`. If lto-plugin launches lto-wrapper with this arguments and it returns success, then it is known that lto-wrapper will accept the temporary file to output the file names to ld. If it fails, then it is known that lto-wrapper is unpatched and lto-plugin should proceed the old way. However, I would like to know if this is a suitable solution, or if won't be accepted for other reasons. > > There's stderr for debugging... One could do `sys.stdout = sys.stderr` in the python code, but it doesn't seems to be an nice solution... Giuliano. > > > I've run a full testsuite and bootstrapped LTO in a linux x86_64, and found > > no issues so far. Do I need to write a testcase for this feature? > > > > Giuliano. > > > > gcc/ChangeLog > > 2019-10-16 Giuliano Belinassi <giuliano.belina...@usp.br> > > > > * lto-wrapper.c (STATIC_LEN): New macro. > > (to_ld): New. > > (find_crtofftable): Print to file to_ld. > > (find_ld_list_file): New. > > (main): Check if to_ld is valid or is stdout. > > > > gcc/libiberty > > 2019-10-16 Giuliano Belinassi <giuliano.belina...@usp.br> > > > > * pex-unix.c (pex_unix_exec_child): check for PEX_KEEP_STD_IO flag. > > (to_ld): New. > > > > gcc/include > > 19-10-16 Giuliano Belinassi <giuliano.belina...@usp.br> > > > > * libiberty.h (PEX_KEEP_STD_IO): New macro. > > > > gcc/lto-plugin > > 2019-10-16 Giuliano Belinassi <giuliano.belina...@usp.br> > > > > * lto-plugin.c (exec_lto_wrapper): Replace pipe from stdout to temporary > > file, and pass its name in argv. > >
