[llvm-commits] [llvm] r127540 - in /llvm/trunk: include/llvm/MC/MCSection.h include/llvm/MC/MCSectionELF.h lib/CodeGen/AsmPrinter/AsmPrinterDwarf.cpp

[Jan Sjodin]

I had accidentally put this comment for a different patch:

> I was continuing to try and see what the problem actually was. The  difference 
>between the machines was that th debuginfo for glibc was  included on the test 
>machine but not my own. I did a small test and  linked in a dummy 
>
> file before the test file and was able to reproduce  the issue. This means that 
>there is a bug somewhere else or that the  "optimization" is really something 
>required and the comment should be  updated
>
>- Jan

In any case I think I am stuck and need some help.  I found the two offsets in 
the generated .s files that causes the bug:

.Lset32 = .Labbrev_begin-.Lsection_abbrev # Offset Into Abbrev. Section
    .long    .Lset32

and

.Lset34 = .Linfo_begin1-.Lsection_info  # Offset of Compilation Unit Info
    .long    .Lset34

This will not work unless the resulting .o file appears first in the list of 
files to be linked, or if all object files before do not have any debug 
information.

Without the patch these look like:
.long    .Labbrev_begin          # Offset Into Abbrev. Section
and
 .long    .Linfo_begin1           # Offset of Compilation Unit Info

In lib/CodeGen/AsmPrinter/AsmPrinterDwarf.cpp we have this code:
// 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;
 }
  
The comment for the optimization cannot be true since without this, the 
generated code is wrong. I wanted to know why the above values cannot be 
differences, but have to be direct references. Is it a different kind of offset? 
If so, should LLVM distinguish between different kinds of offsets? I would be 
happy if someone with more knowledge could explain.

- Jan



________________________________
From: Jan Sjodin <jan_sjodin at yahoo.com>
To: Rafael Avila de Espindola <rafael.espindola at gmail.com>; 
llvm-commits at cs.uiuc.edu
Sent: Thu, March 17, 2011 5:59:13 PM
Subject: Re: [llvm-commits] [llvm] r127540 - in /llvm/trunk: 
include/llvm/MC/MCSection.h include/llvm/MC/MCSectionELF.h 
lib/CodeGen/AsmPrinter/AsmPrinterDwarf.cpp


Test machine: GNU ld (GNU Binutils for Debian) 2.18.0.20080103
My machine: GNU ld (GNU Binutils for Ubuntu) 2.20.51-system.20100908

I actually did a few different things to see if I could possibly reproduce the 
problem on my machine.
1. I downloaded the closest versions of gdb, gcc and binutils that i could find:
   Test machine: gcc (Debian 4.3.2-1.1) 4.3.2,  GNU gdb 6.8-debian and binutils 
(see above)
   Downloaded and compiled: gcc 4.3.2, gdb 6.8 and  binutils 2.18
2. Compiled llvm, llvm-gcc with these and was not able to reproduce the problem.
3. Copied the ld binary and libbfd-2.18.0.20080103.so from the test machine to 
my own machine to see if I could use that linker to reproduce the error, and 
still was not able to reproduce the  problem.

There is something weird going on with that specific machine and I have no clue 
what it is. I know that ld is involved somehow. Perhaps it is some other 
supporting library that is at fault.

- Jan




________________________________
From: Rafael Avila de Espindola <rafael.espindola at gmail.com>
To: llvm-commits at cs.uiuc.edu
Sent: Thu, March 17, 2011 4:41:03 PM
Subject: Re: [llvm-commits] [llvm] r127540 - in /llvm/trunk: 
include/llvm/MC/MCSection.h include/llvm/MC/MCSectionELF.h 
lib/CodeGen/AsmPrinter/AsmPrinterDwarf.cpp

On 11-03-17 03:57 PM, Jan Sjodin wrote:
> I have been investigating this failure for the past couple of days.
> There is something wrong with the linker on the test machine. If i take
> the generated asm file (.s) and assemble and link on my own machine it
> works fine. If i assemble on the test machine and link on my machine it
> works fine, but if I link on the test machine the ELF format becomes
> corrupted somehow. This shows up e.g. with readelf -a, where the object
> file is okay, but the binary does not list the symbol table (it is there
> and can be listed with readelf -s) The patch should be good otherwise,
> the object file is smaller with the patch than without.

What are the liker versions on both cases?

> - Jan

Cheers,
Rafael
_______________________________________________
llvm-commits mailing list
llvm-commits at cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20110322/9c4d961c/attachment.html>