Re: [gentoo-dev] TEXTRELs in assembly program

[Nekun]

On 2021-04-22 21:23, Sam James wrote:
> Such pkg_setups are best avoided if possible because they can be
> confusing and we have other tools to handle it, so I’m glad you asked!
> I’d provide a USE flag for this tool and mask it on non-multilib amd64
> profiles (or mask everywhere and unmask on the multilib amd64
> profiles).
Fasm itself can be built and run in pure amd64 environment, so we need 
to mask only USEs for building additional tools and building fasm itself 
against libc in non-multilib amd64 (native x86 is correct platform too) 
it this approach.

> 1) The TEXTREL QA warning primarily exists because of the security
> issues associated with them - they prevent PIC.
>
> The following links may be useful:
> -
> https://flameeyes.blog/2016/01/16/textrels-text-relocations-and-their-impact-on-hardening-techniques/
> - https://wiki.gentoo.org/wiki/Hardened/Textrels_Guide
>
> However, I think it’s not really likely to be a real world issue if
> the program in question is an assembler. You’re just going to hit
> possible portability issues
> but I’m not sure what the details are there.
Seems like gcc when used as linker frontend expects PIE-aware code in 
object file and pass '-pie' to linker, but fasm doesn't know anything 
about PIE, so ld fallbacks to TEXTRELs, AFAIK. Suggest two approaches: 
disable passing PIE in gcc in some way or ignore textrel issues. Manual 
linking seems to be error-prone in any non-standard configuration, such 
as ${ROOT}/${SYSROOT} cross-environments, binary hosts, etc... maybe I 
too scared because not so familiar with linking, however.

> 2) Passing -fno-PIE and friends should work if you use append-* from
> flag-o-matic.eclass?
Passing -fno-pie to gcc has no effect, `strace --string-limit -vfe 
execve` shows that '--pie' is passed to ld anyway.

> Can’t see it here.
Looks like it accidentaly not posted by my stupid webmail client, posted 
in plaintext in reply to original post.