[PATCH 02/57] Support scanning of build-time GC roots in gengtype

[Bill Schmidt]

On 6/9/21 5:54 AM, Richard Biener wrote:
> On Wed, Jun 9, 2021 at 12:53 PM Richard Biener
> <richard.guenther@gmail.com> wrote:
>> On Tue, Jun 8, 2021 at 10:45 PM Bill Schmidt <wschmidt@linux.ibm.com> wrote:
>>> On 6/7/21 12:48 PM, Bill Schmidt wrote:
>>>> On 6/7/21 12:45 PM, Richard Biener wrote:
>>>>> On Mon, Jun 7, 2021 at 5:38 PM Bill Schmidt <wschmidt@linux.ibm.com>
>>>>> wrote:
>>>>>> On 6/7/21 8:36 AM, Richard Biener wrote:
>>>>>>> Some maybe obvious issue - what about DOS-style path hosts?
>>>>>>> You seem to build ../ strings to point to parent dirs... I'm not sure
>>>>>>> what we do elsewhere - I suppose we arrange for appropriate
>>>>>>> -I command line arguments?
>>>>>>>
>>>>>> Well, actually it's just using "./" to identify the build directory,
>>>>>> though I see what you mean about potential Linux bias. There is
>>>>>> precedent for this syntax identifying the build directory in config.gcc
>>>>>> for target macro files:
>>>>>>
>>>>>> #  tm_file              A list of target macro files, if different from
>>>>>> #                       "$cpu_type/$cpu_type.h". Usually it's
>>>>>> constructed
>>>>>> #                       per target in a way like this:
>>>>>> #                       tm_file="${tm_file} dbxelf.h elfos.h
>>>>>> ${cpu_type.h}/elf.h"
>>>>>> #                       Note that the preferred order is:
>>>>>> #                       - specific target header
>>>>>> "${cpu_type}/${cpu_type.h}"
>>>>>> #                       - generic headers like dbxelf.h elfos.h, etc.
>>>>>> #                       - specializing target headers like
>>>>>> ${cpu_type.h}/elf.h
>>>>>> #                       This helps to keep OS specific stuff out of
>>>>>> the CPU
>>>>>> #                       defining header ${cpu_type}/${cpu_type.h}.
>>>>>> #
>>>>>> #                       It is possible to include
>>>>>> automatically-generated
>>>>>> #                       build-directory files by prefixing them with
>>>>>> "./".
>>>>>> #                       All other files should relative to
>>>>>> $srcdir/config.
>>>>>>
>>>>>> ...so I thought I would try to be consistent with this change. In patch
>>>>>> 0025 I use this as follows:
>>>>>>
>>>>>> --- a/gcc/config.gcc
>>>>>> +++ b/gcc/config.gcc
>>>>>> @@ -491,6 +491,7 @@ powerpc*-*-*)
>>>>>>            extra_options="${extra_options} g.opt fused-madd.opt
>>>>>> rs6000/rs6000-tables.opt"
>>>>>>            target_gtfiles="$target_gtfiles
>>>>>> \$(srcdir)/config/rs6000/rs6000-logue.c
>>>>>> \$(srcdir)/config/rs6000/rs6000-call.c"
>>>>>>            target_gtfiles="$target_gtfiles
>>>>>> \$(srcdir)/config/rs6000/rs6000-pcrel-opt.c"
>>>>>> +       target_gtfiles="$target_gtfiles ./rs6000-builtins.h"
>>>>>> ;;
>>>>>>     pru-*-*)
>>>>>> cpu_type=pru
>>>>>>
>>>>>> I'm open to trying to do something different if you think that's
>>>>>> appropriate.
>>>>> Well, I'm not sure whether/how to resolve this.  You could try
>>>>> building a cross to powerpc-linux from a x86_64-mingw host ...
>>>>> maybe there's one on the CF?  Or some of your fellow RedHat
>>>>> people have access to mingw or the like envs to try whether it
>>>>> just works with your change ...
>>>>>
>>>>> Otherwise it looks OK.
>>>> I'll see what I can find.  Thanks again for reviewing the patch!
>>>
>>> Hm.  Ultimately, I think the cross compiler case is doomed unless mingw
>>> already handles converting forward slashes to back slashes. There's no
>>> single syntax that works on both Windows and Linux. (There's no mingw
>>> server in the compile farm to play with.)
>>>
>>> I'm inclined to accept both "./" and ".\" for native builds, and kick
>>> the can down the road beyond that.  What do you think?
>> Can't you use PATH_SEPARATOR somehow?  See file-find.c / incpath.c
>> or gcc.c for uses and system.h for where it is defined.
> Err - DIR_SEPARATOR of course.

Ah -- following the breadcrumbs a little further, it appears that 
IS_DIR_SEPARATOR is the proper way to handle both Linux- and 
Windows-style syntax.  Thanks for the pointer!  That should work. Will test.

Bill

>
> Richard.
>
>> Richard.
>>
>>> Bill
>>>
>>>> Bill
>>>>
>>>>
>>>>> Richard.
>>>>>
>>>>>> Thanks for your help with this!
>>>>>>
>>>>>> Bill
>>>>>>