All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Yu, Mingli" <mingli.yu@windriver.com>
To: Alexander Kanavin <alex.kanavin@gmail.com>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [PATCH] boost: Improve reproducibility
Date: Tue, 5 Jun 2018 10:44:55 +0800	[thread overview]
Message-ID: <5B15F927.2020504@windriver.com> (raw)
In-Reply-To: <CANNYZj_saa2orMaM15wGZuDF8W0=JmAuz2eADMA5zjwknvSByw@mail.gmail.com>



On 2018年06月01日 16:36, Alexander Kanavin wrote:
> 2018-06-01 8:38 GMT+03:00 Yu, Mingli <mingli.yu@windriver.com>:
>
>> I did investigate the path a lot before send out the patch, but didn't
>> figure out why it introduce the path for make_x86_64_sysv_elf_gas.o whose
>> source file is make_x86_64_sysv_elf_gas.S.
>>
>> Anyway, I will try to dig more.
>>
>> If you have any ideas, welcome to help provide some hint.
>
> I'm not an expert in symbol tables and what goes into them, but I
> strongly suspect the full path is introduced by linker because that .S
> file has two assembly labels (trampoline, finish). The other two
> assembly files have no such labels, and so their file paths are not
> added to the .so. I'm also not sure why there needs to be a full path,

Thanks Alex very much for your comments!
I think the full path is introduced by linker and I'm also confused why 
other two assembly files' o file not introduced in the final .so.


> as opposed to just the file name, as is the case for .c files (maybe
> to avoid clashes with labels of the same name in different files?).

I'm also concerned about that maybe it's necessary to have the full path.

Thanks,


>
> We should probably just strip that one specific .o file before it's
> linked into the library. Or if there is a way to prevent the labels
> from being written into the symbol table by the assembler, we can use
> that too. Sadly boost has its own build system, so doing such custom
> tweaks may be tricky.
>
> Alex
>


  reply	other threads:[~2018-06-05  2:48 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-31  6:20 [PATCH] boost: Improve reproducibility mingli.yu
2018-05-31 13:13 ` Richard Purdie
2018-06-01  1:39   ` Yu, Mingli
2018-06-01  5:08     ` Alexander Kanavin
2018-06-01  5:38       ` Yu, Mingli
2018-06-01  8:36         ` Alexander Kanavin
2018-06-05  2:44           ` Yu, Mingli [this message]
2018-06-01 17:07         ` Khem Raj
2018-06-01 17:56           ` Alexander Kanavin
2018-06-01 18:33             ` Khem Raj
2018-06-01 19:34               ` Alexander Kanavin
2018-06-15  6:44                 ` Khem Raj
2018-06-15  6:54                   ` Alexander Kanavin
2018-06-15  7:31                     ` Yu, Mingli

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=5B15F927.2020504@windriver.com \
    --to=mingli.yu@windriver.com \
    --cc=alex.kanavin@gmail.com \
    --cc=openembedded-core@lists.openembedded.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.