[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH RFC] x86/lld: fix symbol map generation


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Date: Thu, 5 May 2022 10:39:05 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=zsPBDF3S1NCYyGFfu8Ws9je3Ze4yh0Ma5fIOOJOMJE4=; b=Y1zOD48KkJAg/0yb4/TDFcQ3FLv/hK5rkRubY1FZEcDG4kqfXasSRiertLAu73407VIK+Lqg5ICxe9LuwWn4ezc6WYVRi5WujP+sRe4lt9PTNCA7ioRQJ2U65b2rPBLhI9kz1Zm0pMLb1Tv9gTPSy2oQNzv0SGL32x9X4ZiJ4nVUZJ4iXZrDujCZ5HRKysjseJQq/v3m28F+R1ZLcp/DRaeCFbxprWo9JD1Ojfi0vG6wgoRWJvM2b44YQWCubptD07KzTxa4d3J4C+YWPt0wVQnGvuP3KqPyRADqSCZ8SybFND6H6bN+pFAjdQ113qD8DDvBR/jIIzbEvoFJmB65CA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JzLajnfe1tOir8zYV2QeSGWvBihSjTca8fw4ZwFTmP0KrheLauq2kROeGDXURgG2o6d8zjXOw7rwOpW5V7tLl145EzjrnziPM7XEG5G4mzIGNsCjQkOr0GfneEmoB67fsQIXfmi8UdRRo/VTcDiFqeQGAXr8FTYNMiPm7ac8Vbi05P2e2YR6adFufm60MUloMfQCD7nOSX69KHiAsU//oK9LYMRJmhrP73OQB70n3NmcWSRIYQFOjwFjNMCn1FKYmFExRRXptbfOAIJhJAVykMZGeXnHQaWOae+Vhgq8PpYAlfQeTidqH7iXd8/byhDqInon55UPydliK99FmQwOEQ==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
  • Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Thu, 05 May 2022 08:39:20 +0000
  • Ironport-data: A9a23:T1GwnKMaXD+pFrzvrR3RlsFynXyQoLVcMsEvi/4bfWQNrUom0GAOn zBNC22Ab/mNYDP3KtFwatixoB4F65/TzoBjTAto+SlhQUwRpJueD7x1DKtR0wB+jCHnZBg6h ynLQoCYdKjYdleF+lH1dOKJQUBUjclkfJKlYAL/En03FFYMpBsJ00o5wbZk2tMw2LBVPivW0 T/Mi5yHULOa82Yc3lI8s8pvfzs24ZweEBtB1rAPTagjUG32zhH5P7pGTU2FFFPqQ5E8IwKPb 72rIIdVXI/u10xF5tuNyt4Xe6CRK1LYFVDmZnF+A8BOjvXez8CbP2lS2Pc0MC9qZzu1c99Zk eVN7L+LFl0SeayRlvYCVSldFj1aMvgTkFPHCSDXXc276WTjKiKp79AwSUY8MMsf5/p9BnxI+ boAMjcRYxufhuWwhrWmVu1rgcdlJ87uVG8dkig4kXeFUrB7HtaaHfWiCdxwhV/cguhUGvnTf YwBYCdHZxXceRxffFwQDfrSmc/33iejI2wJ9jp5o4I++0GJkSpaz4T3H4XrQs2XHZsWhkyh8 zeuE2PRR0ty2Mak4TiP/2+oh+TPtTjmQ49UH7q9ntZ1hHWDy2pVDwcZPXOrrP/8hkOgVtZ3L 00P5jFovaU07FasTNT2Q1u/unHsg/IHc99ZEul/5ATTzKPRul+dHjJdEG4Hb8E6vsgrQzBsz kWOg97iGT1otvuSVG6Z8bCX6zi1PED5MFM/WMPNdiNdi/GLnW35pkinogpLeEJtsuDIJA==
  • Ironport-hdrordr: A9a23:b8iOL60iJLJ1aW8agFY+qQqjBSByeYIsimQD101hICG9Lfb0qy n+pp4mPEHP4wr5OEtOpTlPAtjkfZr5z+8M3WB3B8bYYOCGghrQEGgG1+ffKlLbexEWmtQttp uINpIOcuEYbmIK8voSgjPIdOrIqePvmM7IuQ6d9QYKcegDUdAd0+4TMHf+LqQZfnglOXJvf6 Dsm/av6gDQMEg/X4CePD0oTuLDr9rEmNbPZgMHPQcu7E2rgSmz4LD3PhCE1lNGOgk/iosKwC zgqUjU96+ju/a0xlv10HLS1Y1fnJ/ExsFYDMKBp8AJInHHixquZq5mR7qe1QpF6N2H2RIPqp 3hsh0gN8N85zf4eXy0mwLk303a3DMn+xbZuCulqEqmhfa8aCMxCsJHi44cWADe8VAcsNZ117 8O936FtrJMZCmw0xjV1pztbVVHh0C0qX0tnao4lHpES7YTb7dXsMg24F5VKpEdByj3gbpXXN WGNPuspcq+TGnqL0ww5gJUsZ+RtzUIb1q7q3E5y4KoO2M8pgE686MarPZv60vouqhNDqWs3N 60Q5iApIs+MPP+UpgNdNvpYfHHfVAlEii8Rl57HzzcZdI6EkOIjaLLy5MIw8zvUKA07fIJ6e b8uRVjxCQPR34=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On Tue, May 03, 2022 at 10:17:44AM +0200, Jan Beulich wrote:
> On 02.05.2022 17:20, Roger Pau Monne wrote:
> > The symbol map generation (and thus the debug info attached to Xen) is
> > partially broken when using LLVM LD.  That's due to LLD converting
> > almost all symbols from global to local in the last linking step, and
> 
> I'm puzzled by "almost" - is there a pattern of which ones aren't
> converted?
> 
> Also "last linking step" is ambiguous, as we link three binaries and
> aiui the issue is present on every of these passes. May I suggest
> "... when linking actual executables" or (still somewhat ambiguous)
> "... when linking final binaries"?
> 
> > thus confusing tools/symbols into adding a file prefix to all text
> > symbols, the results looks like:
> > 
> > Xen call trace:
> >    [<ffff82d040449fe8>] R xxhash64.c#__start_xen+0x3938/0x39c0
> >    [<ffff82d040203734>] F __high_start+0x94/0xa0
> > 
> > In order to workaround this create a list of global symbols prior to
> > the linking step, and use objcopy to convert the symbols in the final
> > binary back to global before processing with tools/symbols.
> > 
> > Signed-off-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
> > ---
> > I haven't found a way to prevent LLD from converting the symbols, so
> > I've come up with this rather crappy workaround.
> 
> Perhaps a map file (like we use for shared libraries in tools/) would
> allow doing so? But of course this would want to be machine-generated,
> not manually maintained.
> 
> Have you gained any insight into _why_ they are doing what they do?

So after raising this in the LLVM LD forum, I was told this behavior
is due to the spec:

"A hidden symbol contained in a relocatable object must be either
removed or converted to STB_LOCAL binding by the link-editor when the
relocatable object is included in an executable file or shared
object."

Then I did some search myself and found that you raised the same with
GNU ld not doing the conversion:

https://sourceware.org/bugzilla/show_bug.cgi?id=12374

So it seems LLVM LD goes a bit further than GNU ld and also changes
the binding of symbols in the .symtab.  I'm not sure I would consider
the behavior of either linkers wrong.

As a test I've attempted to disable the hidden visibility setting we
set in compiler.h, just to realize that parts of our code do rely on
having hidden visibility.  That's the bug and alternative constructs
that use the "i" asm constrain with function pointers.  That's only
possible in the absence of a GOT or PLT table:

https://godbolt.org/z/jK3bq4fhe

So I think the way to fix this would be to set the visibility to
protected instead of hidden, and then to also make the setting of the
visibility unconditional: the compiler not supporting -fvisibility and
Xen not setting it will just lead to compiler errors further on during
the build process.

Thanks, Roger.



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.