This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

ld -shared --eh-frame-hdr gives empty eh_frame_hdr


Gidday,

So I was trying compile a small shared library (on x86 with: gcc 3.3.4 +
binutils 2.15) without -fpic:

  $ gcc -c -funwind-tables -o foo.o foo.c
  $ ld --eh-frame-hdr -shared -o foo.so foo.o

This produces an eh_frame_hdr WITHOUT an FDE table, which I was hoping
to use for unwinding call stacks (libunwind). Using -fpic will produce
the table, but I don't have the option of doing so, afaik this isn't
required for x86. Is there a why around this ?

I only have a basic understanding of the DWARF2, but I assume this
posting:

http://sources.redhat.com/ml/binutils/2002-02/msg00660.html

is relative, Jakub Jelinek wrote:

"In addition to this, if this optimization is not possible and FDE  
encoding is still DW_EH_PE_absptr, doesn't create the binary search
table in .eh_frame_hdr. I thought about making this work anyway, but the
code would need to have at least some understanding of ELF target relocs
which doesn't look like 2.12 material."

Are there plans for this to work, I understand .eh_frame_hdr isn't just
a direct copy from .eh_frame ? 

Otherwise I guess it should be possible to read and parse FDEs from
.eh_frame for call frame information (e.g. populate libunwind).

Cheers.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]