<div dir="ltr"><div><div><div><div><div><div>Hi<br></div>Runtime Output i pasted was from gdb asm layout, which appears exactly same as what you mentioned,with objdump -rd<br><br></div>I have done <br>readelf -x .rodata objfile <br></div>neither of strings str or str1 appear in output, so that <i>does confirm strings are not in data section.</i><br><br></div>My triple however looks something like this<span style="color:rgb(0,0,255)"> X86_64-unknown-linux-gnu. which is okay,i guess?</span><br></div><br></div><div>I have created objfile from llc directly (so no g++), same behavior. <br><span style="color:rgb(142,124,195)"><br><span style="color:rgb(56,118,29)"><span style="background-color:rgb(238,238,238)">could it be issue with llvm ir ?<br></span></span></span></div><div><span style="color:rgb(142,124,195)"><span style="color:rgb(56,118,29)"><span style="background-color:rgb(238,238,238)">IR declarations are <br></span></span></span></div><div>$.str = comdat any<br>
$.str.1 = comdat any<br>@.str = linkonce_odr unnamed_addr addrspace(2) constant [7 x i8] c"OhNo!\0A\00", comdat, align 64<br>@.str.1 = linkonce_odr unnamed_addr constant [21 x i8] c"**** extent ****\0A\00", comdat, align 1<br></div><div><br></div><div>Mahesh<br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Apr 23, 2018 at 4:10 PM, Tim Northover <span dir="ltr"><<a href="mailto:t.p.northover@gmail.com" target="_blank">t.p.northover@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Mahesh,<br>
<br>
On 23 April 2018 at 10:51, Mahesh Attarde via llvm-dev<br>
<<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br>
> movq .str@GOTPCREL(%rip),%rdi<br>
> movq .str.1@GOTPCREL(%rip),%rsi<br>
<br>
That's quite strange. You wouldn't normally expect to access a<br>
constant string via the GOT. It looks like LLVM has decided to put the<br>
symbols in an odd section, so it'd be a good idea to make sure your<br>
entire triple matches GCC (e.g. -mtriple=x86_64-linux-gnu or<br>
x86_64-apple-macosx or whatever).<br>
<br>
> mov  0x0(%rip),%rdi<br>
> mov  0x0(%rip),%rsi<br>
<br>
Is this really at runtime, or are you inspecting the .o file? If it's<br>
the .o file this is pretty normal. GCC will have recorded a bunch of<br>
relocations in a different place, telling the linker how to fix these<br>
accesses up so they really do end up pointing to different strings.<br>
"objdump -rd" would print them alongside the disassembly.<br>
<br>
If it's at runtime, you still want to look at the object file to find<br>
out whether it's GCC or your linker that's made the mistake (or LLVM,<br>
of course; maybe it's not just me that was surprised by the llc<br>
output, but GCC couldn't cope either).<br>
<br>
Cheers.<br>
<span class="HOEnZb"><font color="#888888"><br>
Tim.<br>
</font></span></blockquote></div><br></div>