[llvm-commits] Change DwarfUsesAbsoluteLabelForStmtList to false for X86ELFMCAsmInfo.

Renato Golin Renato.Golin at arm.com
Fri Mar 25 09:52:04 PDT 2011


Hey, this is exactly what my patch was doing! ;)

http://llvm.org/bugs/show_bug.cgi?id=9493

but it was reverted since it broke Darwin,

http://llvm.org/bugs/show_bug.cgi?id=9497


Your patch looks remarkably similar to mine, though maybe the change in yours is in the right place. ;)

If you can make both bugs above pass, I'm happy with the patch.

cheers,
--renato

________________________________________
From: llvm-commits-bounces at cs.uiuc.edu [llvm-commits-bounces at cs.uiuc.edu] On Behalf Of Jan Sjodin [jan_sjodin at yahoo.com]
Sent: 25 March 2011 16:04
To: Anton Korobeynikov; Devang Patel
Cc: llvm-commits at cs.uiuc.edu
Subject: Re: [llvm-commits] Change DwarfUsesAbsoluteLabelForStmtList to false for X86ELFMCAsmInfo.

I found this discussion on llvm-dev:
http://lists.cs.uiuc.edu/pipermail/llvmdev/2010-August/034104.html

This shows that my patch is correct in the sense that it does emit an offset
(dwarfdump complained about the type of the entry not being DW_FORM_data4), but
my patch would theoretically not work for ELF since it requires an absolute
label so that a relocation is created. The thing is that the absolute label vs.
label difference is not limited  to the stmt list, but is true for debug_abbrev,
debug_pubnames etc. My patch relies like the other sections on this conversion
(which is not an optimization at all, but actually ensures that a relocation
will be created) in:

AsmPrinterDwarf.cpp:194:
  // If the section in question will end up with an address of 0 anyway, we can
  // just emit an absolute reference to save a relocation.
  if (Section.isBaseAddressKnownZero()) {
    OutStreamer.EmitSymbolValue(Label, 4, 0/*AddrSpace*/);
    return;
  }

This code converts the difference into the direct reference needed in ELF. I do
not know why there was a problem specifically with section_line back then, but
apparently that was fixed since I could now disable the check: if
(Asm->MAI->doesDwarfUsesAbsoluteLabelForStmtList()) and rely on the conversion
later on. Like I mentioned earlier, what dwarfdump really complained about was
the type of the entry. I could equally rewrite my patch like this:
Index: lib/CodeGen/AsmPrinter/DwarfDebug.cpp
===================================================================
--- lib/CodeGen/AsmPrinter/DwarfDebug.cpp    (revision 128274)
+++ lib/CodeGen/AsmPrinter/DwarfDebug.cpp    (working copy)
@@ -1925,7 +1925,7 @@
   // DW_AT_stmt_list is a offset of line number information for this
   // compile unit in debug_line section.
   if (Asm->MAI->doesDwarfUsesAbsoluteLabelForStmtList())
-    addLabel(Die, dwarf::DW_AT_stmt_list, dwarf::DW_FORM_addr,
+    addLabel(Die, dwarf::DW_AT_stmt_list, dwarf::DW_FORM_data4,
              Asm->GetTempSymbol("section_line"));
   else
     addUInt(Die, dwarf::DW_AT_stmt_list, dwarf::DW_FORM_data4, 0);

The reason why gdb did not complain about this is probably that the type was
ignored and everything worked since the data was correct.

The question is what the proper cleanup should be. We could simply remove the
doesDwarfUsesAbsoluteLabelForStmtList and make EmitSectionOffset decide if a
label reference or a label difference should be emitted. The alternative would
be to eliminate the conversion in EmitSectionOffset and expand
doesDwarfUsesAbsoluteLabelForStmtList into something like
doesDwarfUsesAbsoluteLabelForSections (I don't know if it is limited to certain
sections), and change DwarfDebug to add labels and emit symbol values instead of
just using EmitSectionOffset. I do not know what is best in this case, but
having both mechanisms is not clean.

- Jan

________________________________
From: Anton Korobeynikov <anton at korobeynikov.info>
To: Jan Sjodin <jan_sjodin at yahoo.com>
Cc: llvm-commits at cs.uiuc.edu
Sent: Tue, March 22, 2011 7:50:19 PM
Subject: Re: [llvm-commits] Change DwarfUsesAbsoluteLabelForStmtList to false
for X86ELFMCAsmInfo.

Hi Jan

> Ping!
The patch looks ok for me, but could you please look into dwarf
standard to check which behavior is per standard,

Thanks!

--
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University

_______________________________________________
llvm-commits mailing list
llvm-commits at cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits


-- 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.





More information about the llvm-commits mailing list