On Mon, Jul 20, 2020 at 1:04 PM Andrew Stubbs <a...@codesourcery.com> wrote: > > 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.
It shouldn't do that. > 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. Even with LTO we cannot say for sure a symbol will survive optimization so the early debug has to be self-contained and linkable without any prerequesites. Otherwise you hit a latent bug. That said, there will still be some data relocations to/from debug sections, mainly .debug_info referencing .debug_str + offset but maybe also some others. I would have hoped there are "common" ELF relocation types with the same relocation types across targets for this ... but oh well. > 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. As said it shouldn't be necessary and just hides an existing bug. Richard. > Andrew
