On 20/07/2020 11:01, Richard Biener wrote:
On Mon, Jul 20, 2020 at 10:40 AM Andrew Stubbs <a...@codesourcery.com> wrote:
On 20/07/2020 08:35, Richard Biener wrote:
The way simple_object is supposed to work is to clone (or merge) the ELF
headers from an existing binary. Unfortunately, the way mkoffload is
currently coded we don't have any to clone from until too late. We could
separate the assemble and link steps, but I chose not to go that way at
this time.
You could defer the debug copying to after mkoffload assembled the
offloaded code and use those objects as template. Maybe that's
what you refer to with separating assemble and link steps.
That's exactly it.
We'd still have to solve the relocation and symbol issues though, so for
now we may as well solve both problems in one place.
Does it even make sense to add support for those steps to simple_object?
The relocation translation is highly target-specific, of course. The
symbol weakening is necessary because the early debug info contains
references to symbols that will not exist in the offloaded code (leading
to either link failure or bloat).
The odd thing is that the early debug should _not_ contain any relocations
to data nor extra symbols. Only relocations within the debug info
should be there.
The problem with the relocations themselves is only that the x86_64
relocation codes don't match the amdgcn codes, making them gibberish to
the linker.
As for the symbol references, I observed it trying to link in symbols
that only exist in the host libgomp. My assumption is that the generated
early debug was intended for the LTO use-case, in which the output
program will contain everything, and that this is merely the first
offload target to support debug in this way. If it's not supposed to
have those references at all then I'm out of my depth.
I can't say for sure whether the debug info generated with my patch is
broken or misleading (because I'm clueless), but weakening the symbols
works for the test cases and debug sessions that I tried.
Andrew
