<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=gb2312">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"MS Gothic";
panose-1:2 11 6 9 7 2 5 8 2 4;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:"\@MS Gothic";
panose-1:2 11 6 9 7 2 5 8 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style>
</head>
<body lang="EN-US" link="blue" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal"><span style="color:black">Hi<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">The file contents and the commands to build and test are below. assuming that you have clang++, ld.lld, ld, sed, curl and gdb installed, the commands are at the end of this email.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">Just copy paste the lines below each file name into that file on your computer, then run the commands at the end. You¡¯ll see that the file output linked with ld will load into gdb without any error but the output
linked with ld.lld will produce errors when loaded into gdb<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:black">A<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:black">******** Minimal example : <o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">------------------ file.h<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">const char * get_char_value (void);<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">const int * get_int_value (void);<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">inline const char * first_inline_function (void) {<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"> return get_char_value ();<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">}<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">inline const int * second_inline_function (void) {<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"> return get_int_value ();<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">}<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">-------------------- file1.cpp<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">#include "file.h"<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">static int data = 5;<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">const int *get_int_value (void) {<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"> return &data;<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">}<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">-------------------- file2.cpp<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">#include "file.h"<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">static const char *data = "something meaningless";<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">const char *get_char_value (void) {<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"> return data;<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">}<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">-------------------- file3.cpp<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">#include "file.h"<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">const char * get_it (void) {<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"> const char *c = first_inline_function();<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"> const int *i = second_inline_function();<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"> return &c[*i];<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">}<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:black">-------------------- commands to build and load into gdb <o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">curl -o ldscript.amd64 https://raw.githubusercontent.com/freebsd/freebsd-src/master/sys/conf/ldscript.amd64<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">sed -i 's/.*kern.*//g' ldscript.amd64<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">sed -i 's/.*freebsd.*//g' ldscript.amd64<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">clang++ -c file1.cpp -o file1.cpp.o<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">clang++ -c file2.cpp -o file2.cpp.o<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">clang++ -c file3.cpp -o file3.cpp.o<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">ld.lld -r -T ldscript.amd64 *.o -o output.ld.lld<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">ld -r -T ldscript.amd64 *.o -o output.ld.bfd<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">echo "============== done building"<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">gdb -batch -ex 'add-symbol-file output.ld.lld 0x1234'<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">echo "============== done loading lld ( Notice the errors above)"<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">gdb -batch -ex 'add-symbol-file output.ld.bfd 0x1234'</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:black">echo "============== done loading lld (Notice that no error is produced here)"<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="margin-bottom:12.0pt"><b><span style="font-size:12.0pt;color:black">From:
</span></b><span style="font-size:12.0pt;color:black">F¨¡ng-ru¨¬ S¨°ng <maskray@google.com><br>
<b>Date: </b>Monday, May 10, 2021 at 4:01 PM<br>
<b>To: </b>Moshtaghi, Alireza <Alireza.Moshtaghi@netapp.com><br>
<b>Cc: </b>llvm-dev@lists.llvm.org <llvm-dev@lists.llvm.org>, Peter Smith <Peter.Smith@arm.com><br>
<b>Subject: </b>Re: [llvm-dev] lld suspect behavior .group/rela/text input sections<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal">NetApp Security WARNING: This is an external email. Do not click links or open attachments unless you recognize the sender and know the content is safe.<br>
<br>
<br>
<br>
<br>
On Mon, May 10, 2021 at 3:57 PM Moshtaghi, Alireza<br>
<Alireza.Moshtaghi@netapp.com> wrote:<br>
><br>
> sending it again to the list<br>
<br>
I am still waiting for a proper reproduce. Your commands have<br>
file1.cpp but your attachment has just file1.h.<br>
<br>
><br>
><br>
> From: Moshtaghi, Alireza <Alireza.Moshtaghi@netapp.com><br>
> Date: Saturday, May 1, 2021 at 10:53 PM<br>
> To: F¨¡ng-ru¨¬ S¨°ng <maskray@google.com><br>
> Cc: Peter Smith <Peter.Smith@arm.com><br>
> Subject: Re: [llvm-dev] lld suspect behavior .group/rela/text input sections<br>
><br>
> Oh<br>
><br>
> Im sorry, I had typo in the file names<br>
><br>
> file.h is the only header file; the other 3 are c++ files. (C may also do but I just use clang++)<br>
><br>
> And of course you only compile the 3 files: file[1,2,3].cpp<br>
><br>
> clang++ -c file1.cpp -o file1.cpp.o<br>
><br>
> clang++ -c file2.cpp -o file2.cpp.o<br>
><br>
> clang++ -c file3.cpp -o file3.cpp.o<br>
><br>
> ld.lld -r -T ldscript.amd64 *.o -o output.ld.lld<br>
><br>
> ld -r -T ldscript.amd64 *.o -o output.ld.bfd<br>
><br>
> gdb -batch ex ¡°add-symbol-file output.ld.lld 0x1234¡±<br>
> gdb -batch ex ¡°add-symbol-file output.ld.bfd 0x1234¡±<br>
><br>
><br>
> ________________________________<br>
><br>
> From: F¨¡ng-ru¨¬ S¨°ng <maskray@google.com><br>
> Sent: Friday, April 30, 2021 2:54:58 PM<br>
> To: Moshtaghi, Alireza <Alireza.Moshtaghi@netapp.com><br>
> Cc: Peter Smith <Peter.Smith@arm.com><br>
> Subject: Re: [llvm-dev] lld suspect behavior .group/rela/text input sections<br>
><br>
><br>
><br>
> NetApp Security WARNING: This is an external email. Do not click links or open attachments unless you recognize the sender and know the content is safe.<br>
><br>
><br>
><br>
><br>
> On 2021-04-30, Moshtaghi, Alireza wrote:<br>
> >Yes, the objects with COMDAT are good examples to show the problem.<br>
> >The problem with lld is when we supply a linker script. Without linker script, lld does the right thing.<br>
> ><br>
> >But with a linker script, it only follows the command to combine .text.* but does not combine respective .rela.text.*<br>
> ><br>
> >This effectively leaves loose ends in the output and makes them problematic with gdb<br>
> ><br>
> >Below there are 4 files. compile them with clang++ and then link with ld.lld as well as ld.bfd and use -r and -T to pass the linker script from the link from my first email in this thread. Call the outputs output.ld.lld and output.ld.bfd respectively.<br>
> >Then load the images into gdb like:<br>
> >gdb -batch ex ¡°add-symbol-file output.ld.lld 0x1234¡±<br>
> >gdb -batch ex ¡°add-symbol-file output.ld.bfd 0x1234¡±<br>
> ><br>
> >you¡¯ll see that the second gdb command succeeds but first one fails and when I investigated I find out that the problem is that lld has merged the .text. _Z22second_inline_functionv and .text. _Z21first_inline_functionv into .text section but the associated
.rela.text.* sections still exist in the output file and gdb fails to recognize these .rela sections because they are part of a group that is missing the text sections.<br>
> ><br>
> >ld.bfd leaves the .text.* sections alone and does not merge them so the group remains intact and gdb succeeds to load them.<br>
> ><br>
> >If I remove the .text.* from the linkerscript, ld.lld does the right thing but I don¡¯t want to do this because that way the text sections that are not part of any group will also not being merged and that is not good.<br>
> ><br>
> >******** Minimal example :<br>
> >--------- file.h<br>
> >const char * get_char_value (void);<br>
> >const int * get_int_value (void);<br>
> >inline const char * first_inline_function (void) {<br>
> > return get_char_value ();<br>
> >}<br>
> >inline const int * second_inline_function (void) {<br>
> > return get_int_value ();<br>
> >}<br>
> >-------------------- file1.h<br>
> >#include "file.h"<br>
> >static int data = 5;<br>
> >const int *get_int_value (void) {<br>
> > return &data;<br>
> >}<br>
> >-------------------- file2.h<br>
> >#include "file.h"<br>
> >static const char *data = "is this really a meaningful?";<br>
> >const char *get_char_value (void) {<br>
> > return data;<br>
> >}<br>
> >-------------------- file3.h<br>
> >#include "file.h"<br>
> >const char * get_it (void) {<br>
> > const char *c = first_inline_function();<br>
> > const int *i = second_inline_function();<br>
> > return &c[*i];<br>
> >}<br>
><br>
> I'm still puzzled. Do you miss some files?<br>
> clang -c file2.h produces a .gch file, unless you specify -xc++.<br>
><br>
> If helps, I use the following script to print reproduce instructions.<br>
> Then users don't need to spend time creating files by themselves.<br>
><br>
> #!/bin/zsh<br>
> dry_run=<br>
> if [[ $1 == --dry-run ]]; then dry_run=1; shift; fi<br>
><br>
> f() {<br>
> for f in $1/*(ND.^x); do<br>
> [[ ${f##*/} =~ '^\.' ]] && continue<br>
> if [[ -n $dry_run ]]; then<br>
> echo $f<br>
> elif [[ $(wc -l < $f) == 1 ]]; then<br>
> echo "echo '$(<$f)' > $f"<br>
> else<br>
> echo "cat > $f <<eof"<br>
> cat $f<br>
> echo eof<br>
> fi<br>
> done<br>
> for d in $1/*(ND/); do<br>
> [[ $d =~ '^\.' ]] && continue<br>
> echo mkdir -p $d<br>
> f $d<br>
> done<br>
> }<br>
><br>
> f ${1:-.}<br>
><br>
> ><br>
> >From: Peter Smith <Peter.Smith@arm.com><br>
> >Date: Thursday, April 29, 2021 at 3:38 AM<br>
> >To: Moshtaghi, Alireza <Alireza.Moshtaghi@netapp.com>, F¨¡ng-ru¨¬ S¨°ng <maskray@google.com><br>
> >Subject: RE: [llvm-dev] lld suspect behavior .group/rela/text input sections<br>
> >NetApp Security WARNING: This is an external email. Do not click links or open attachments unless you recognize the sender and know the content is safe.<br>
> ><br>
> ><br>
> >I can reproduce part of it using ld -r on an object with a COMDAT group.<br>
> ><br>
> >Given that ld -r produces a relocatable object that can be used as input to a subsequent link step retaining the group information and the sections referenced by it uncollated in the ELF file makes sense to me. If the sections were collated into a single
output section and the COMDAT group information lost then there would be multiple definition errors if the relocatable object were combined with other relocatable objects that had COMDAT groups with the same signature.<br>
> ><br>
> >Non COMDAT groups would be possible to collate without affecting subsequent links. Are the groups COMDAT or non COMDAT in your example?<br>
> ><br>
> >My limited understanding is that kernel modules use relocatable objects as kind of dynamically linked object, so there wouldn¡¯t be any recombination, but the static linker doesn¡¯t know what the output of ld -r will be used for.<br>
> ><br>
> >I don¡¯t think the ELF spec covers combination of relocatable objects to output a single relocatable object. It is pretty much implementation defined behaviour from the linker.<br>
> ><br>
> >I¡¯m not sure what to suggest as a resolution. It may be that a relocatable link needs an additional ¡°kernel module¡± or ¡°relocatable object¡± choice to guide the linker as to whether certain types of section should be combined.<br>
> ><br>
> >Peter<br>
> ><br>
> >From: llvm-dev <llvm-dev-bounces@lists.llvm.org> On Behalf Of Moshtaghi, Alireza via llvm-dev<br>
> >Sent: 28 April 2021 23:20<br>
> >To: F¨¡ng-ru¨¬ S¨°ng <maskray@google.com><br>
> >Cc: llvm-dev@lists.llvm.org<br>
> >Subject: Re: [llvm-dev] lld suspect behavior .group/rela/text input sections<br>
> ><br>
> >It is not easy to produce an minimal example. But I will try<br>
> >I was hoping that you may have solved it before.<br>
> >I will come back with an example<br>
> ><br>
> >Thanks<br>
> >A<br>
> ><br>
> >From: F¨¡ng-ru¨¬ S¨°ng <maskray@google.com<mailto:maskray@google.com>><br>
> >Date: Wednesday, April 28, 2021 at 3:11 PM<br>
> >To: Moshtaghi, Alireza <Alireza.Moshtaghi@netapp.com<mailto:Alireza.Moshtaghi@netapp.com>><br>
> >Cc: llvm-dev@lists.llvm.org<mailto:llvm-dev@lists.llvm.org> <llvm-dev@lists.llvm.org<mailto:llvm-dev@lists.llvm.org>><br>
> >Subject: Re: [llvm-dev] lld suspect behavior .group/rela/text input sections<br>
> >NetApp Security WARNING: This is an external email. Do not click links or open attachments unless you recognize the sender and know the content is safe.<br>
> ><br>
> ><br>
> ><br>
> ><br>
> >On Wed, Apr 28, 2021 at 11:02 AM Moshtaghi, Alireza via llvm-dev<br>
> ><llvm-dev@lists.llvm.org<mailto:llvm-dev@lists.llvm.org>> wrote:<br>
> >><br>
> >> Hi<br>
> >><br>
> >> Can you help me to understand if I¡¯m doing anything wrong or the problem is with lld?<br>
> >><br>
> >> I need to use linker-script (below link) for linking freebsd kernel modules and pass -r to ld.lld (version 10) to make these modules relocatable.<br>
> >><br>
> >><br>
> >><br>
> >> Some of the modules that I build are very big and also have .group sections on rela.text.<mangledname> and .text.<mangledname><br>
> >><br>
> >><br>
> >><br>
> >> Per ELF specification these sections should be treated as one and either all merged or none. But I think lld is not respecting that spec and merges all .text.<mangledname> sections while leaving the .group and .rela.text.<mangledname> sections in the output,
which results in broken elf (when I try to load it into gdb, I get Bad Value error)<br>
> >><br>
> >><br>
> >><br>
> >> Alternatively, when I link with ld.bfd, the .text.<manglenames> remain in the output and I¡¯m able to load the object into gdb without error.<br>
> ><br>
> >Hi, do you have a minimal reproducible example<br>
> >(<a href="https://stackoverflow.com/help/minimal-reproducible-example">https://stackoverflow.com/help/minimal-reproducible-example</a>)?<br>
> ><br>
> >Freebsd is not build-friendly when the user is not using FreeBSD ;-)<br>
> ><br>
> >><br>
> >><br>
> >> Linker-script:<br>
> >><br>
> >> <a href="https://github.com/freebsd/freebsd-src/blob/098dbd7ff7f3da9dda03802cdb2d8755f816eada/sys/conf/ldscript.amd64">
https://github.com/freebsd/freebsd-src/blob/098dbd7ff7f3da9dda03802cdb2d8755f816eada/sys/conf/ldscript.amd64</a><br>
> >IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any
purpose, or store or copy the information in any medium. Thank you.<br>
<br>
<br>
<br>
--<br>
<span style="font-family:"MS Gothic"">Ëη½î£</span><o:p></o:p></p>
</div>
</div>
</body>
</html>