Igt-dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Hajda, Andrzej" <andrzej.hajda@intel.com>
To: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: <igt-dev@lists.freedesktop.org>,
	Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>,
	Kamil Konieczny <kamil.konieczny@linux.intel.com>
Subject: Re: [PATCH v2] lib/meson.build: allow build IGT with link time optimization
Date: Fri, 10 Jan 2025 08:58:39 +0100	[thread overview]
Message-ID: <36bf601f-72a7-46cf-9d95-29baea769179@intel.com> (raw)
In-Reply-To: <omr2ioqmwgdfxbdn74mzqar7xdf5sgu6k4wktcr64byyu343o5@xxrp7q4p2hbf>


W dniu 09.01.2025 o 18:29, Lucas De Marchi pisze:
> On Thu, Jan 09, 2025 at 05:26:30PM +0100, Andrzej Hajda wrote:
>> Some distributions use -flto gcc flag to build IGT. With this flag
>> enabled variables declared with section attribute do not appear in
>> correct section in .o files. Since iga64 assembly helper script relies
>> on it we need to use -ffat-lto-objects in case of files containing
>> iga64 assembly. According to documentation this option is effective
>> only in case lto is in use, so it should not affect non-lto builds.
>>
>> Closes: https://gitlab.freedesktop.org/drm/igt-gpu-tools/-/issues/165
>> Signed-off-by: Andrzej Hajda <andrzej.hajda@intel.com>
>
> is this about
>
>         static const char t[] __attribute__ 
> ((section(".iga64_assembly"), used)) =\
> ?
>
> it's missing a "retain" attribute to be able to link with LLD.
> I fixed a similar bug in kmod recently, but that  was due to linking with
> LLD instead of using or not lto. See 
> https://github.com/kmod-project/kmod/pull/274
>
Yes this is about this line, but I think we have here slightly different 
issues.

As I understand in kmod-project you want to keep the symbol in final 
executable/so_library/whatever.

In case of igt we want to have access to ".iga64_assembly" section after 
compile phase (ie see it in .o files), we do not care about final 
executable.

With LTO enabled the structure of .o files drastically changes - every 
function/variable in compile phase goes to separate section 
(.gnu.lto_*), information about final sections is kept somewhere in 
private metadata.

With compiler option '-ffat-lto-objects' .o file contains both 
structures of sections - classic .text/.data/.iga64_assembly and lto 
related .gnu.lto_* and this is what we need in case of igt.


Regards

Andrzej


> Are you sure this is related to LTO and not the different linker?
> $ grep -r -e '\.iga64_assembly' build-lto-clang/
> grep: build-lto-clang/lib/libigt-gpgpu_shader_c.a.p/gpgpu_shader.c.o: 
> binary file matches
> grep: build-lto-clang/lib/libigt.so.0: binary file matches
> grep: build-lto-clang/lib/libigt-gpgpu_fill_c.a.p/gpgpu_fill.c.o: 
> binary file matches
>
>
> $ readelf -t build-lto-clang/lib/libigt.so.0 | grep -A3 -e 
> .iga64_assembly
>   [10] .iga64_assembly
>        PROGBITS         00000000000657d0  00000000000657d0  0
>        0000000000002c65 0000000000000000  0                 16
>        [0000000000000002]: ALLOC
>
> So it has a section with that name of size 0x2c65
>
>
> Lucas De Marchi
>
>> ---
>> This patch 'fixes' building IGT with link-time-optimization. I am not
>> sure it is or should be supported by IGT, but build scripts can be
>> modified to allow it for testing.
>> Grepping internet shows at least Gentoo and Arch Linux builds IGT with
>> LTO, so I guess it is working for them.
>> ---
>> Changes in v2:
>> - added Closes tag
>> - Link to v1: 
>> https://lore.kernel.org/r/20241216-fix-lto-v1-1-1280b17dc70f@intel.com
>> ---
>> lib/meson.build | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/lib/meson.build b/lib/meson.build
>> index 1704ed1e1c17..9fffdd3c6218 100644
>> --- a/lib/meson.build
>> +++ b/lib/meson.build
>> @@ -240,7 +240,7 @@ foreach f: lib_sources
>>         '-DIGT_DATADIR="@0@"'.format(join_paths(prefix, datadir)),
>>         '-DIGT_SRCDIR="@0@"'.format(srcdir),
>>         '-DIGT_LOG_DOMAIN="@0@"'.format(f.split('.')[0]),
>> -    ])
>> +    ] + (iga64_assembly_sources.contains(f) ? [ '-ffat-lto-objects' 
>> ] : []))
>>
>>     lib_intermediates += lib
>>     if iga64_assembly_sources.contains(f)
>>
>> ---
>> base-commit: ee7a3ac616f55f6ed1b959ff951237099bda86d8
>> change-id: 20241216-fix-lto-8d3bc1488c6a
>>
>> Best regards,
>> -- 
>> Andrzej Hajda <andrzej.hajda@intel.com>
>>

  reply	other threads:[~2025-01-10  7:59 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-09 16:26 [PATCH v2] lib/meson.build: allow build IGT with link time optimization Andrzej Hajda
2025-01-09 17:05 ` Kamil Konieczny
2025-01-09 17:29 ` Lucas De Marchi
2025-01-10  7:58   ` Hajda, Andrzej [this message]
2025-01-10 15:49     ` Lucas De Marchi
2025-01-09 17:31 ` ✓ i915.CI.BAT: success for lib/meson.build: allow build IGT with link time optimization (rev2) Patchwork
2025-01-09 18:00 ` ✓ Xe.CI.BAT: " Patchwork
2025-01-12  2:39 ` ✗ Xe.CI.Full: failure " Patchwork
2025-01-14 14:31   ` Kamil Konieczny
2025-01-12 21:32 ` ✗ i915.CI.Full: " Patchwork
2025-01-14 14:32   ` Kamil Konieczny
2025-01-14 14:42 ` [PATCH v2] lib/meson.build: allow build IGT with link time optimization Kamil Konieczny

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=36bf601f-72a7-46cf-9d95-29baea769179@intel.com \
    --to=andrzej.hajda@intel.com \
    --cc=igt-dev@lists.freedesktop.org \
    --cc=janusz.krzysztofik@linux.intel.com \
    --cc=kamil.konieczny@linux.intel.com \
    --cc=lucas.demarchi@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox