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]

Re: PATCH: Don't allow ia64 unwind section to point to section indifferent files


On Fri, 2005-05-13 at 14:46, H. J. Lu wrote:
> When weak functions are used on ia64, part of the unwind section may
> point to the strong definition in a different file. This will lead to
> wrong unwind info. Basically, on ia64, we have to use comdat to get the
> right unwind info. This patch will check it.

This doesn't look like the right fix to me.

I looked at the unwind info with old and new binutils, and noticed that
the relocs are different.  In old binutils, we have
RELOCATION RECORDS FOR [.IA_64.unwind]:
OFFSET           TYPE              VALUE
0000000000000000 SEGREL64LSB       .text
in new binutils we have
RELOCATION RECORDS FOR [.IA_64.unwind]:
OFFSET           TYPE              VALUE
0000000000000000 SEGREL64LSB       _start

Since _start is at offset 0 in .text, these are the same value normally,
but they aren't if we have duplicate weak/strong functions.  Since the
unwind info should always bind locally, I think it is wrong to have the
unresolved _start symbol here.

This change comes from one of Jan Beulich's patches.  It used to be that
unwind.proc_start was expr_build_dot(), now it is set to "sym", which is
the symbol of the current function.  When that change was made, we
didn't know why expr_build_dot was being used here.  Now it appears it
was necessary to fix a problem with bad unwind info in the kernel.

Unfortunately, Jan's change was added to improve unwind info checking,
so we can't easily change back without losing some new features.  But
maybe there is a way to create the relocation differently, so that the
symbol name gets resolved into a section offset in the assembler?  Or
maybe we can create a fake local symbol with the same address to put in
the relocation, to ensure it is resolved locally?  I am not sure of the
best approach here.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com



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