R_SPARC_RELATIVE vs R_SPARC_UA32 & unaligned unwind tables
Ian Lance Taylor
ian@airs.com
Tue Dec 18 20:19:00 GMT 2001
More information about the Binutils mailing list
Tue Dec 18 20:19:00 GMT 2001
- Previous message (by thread): R_SPARC_RELATIVE vs R_SPARC_UA32 & unaligned unwind tables - again
- Next message (by thread): R_SPARC_RELATIVE vs R_SPARC_UA32 & unaligned unwind tables - again
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
DJ Delorie <dj@delorie.com> writes: > > Making a wild guess at the problem, and solution... > > Well, it made a change, but not nearly enough. Before, the value is > something like 0x790000. After, it's like 0x730000. It needs to be > like 0xef790000 (the so is loaded at 0xef730000). What does the reloc look like in the dynamic object? Is it against a symbol or a section? Is the section/symbol being loaded, or is it being dropped? By the way, although it is a good idea to identify this bug, your earlier suggestion of a fde relative offset sounds like a good idea to me. Using any sort of dynamic reloc means that you pay a cost when you run the program, because the dynamic linker must resolve the reloc (except for R_SPARC_JMP_SLOT which can be evaluated lazily). Ideally exception handling should be free except when an exception is thrown. Obviously this ideal is unreachable, but we can move closer to it by eliminating relocations which must be processed by the dynamic linker every time the program is run. Ian
- Previous message (by thread): R_SPARC_RELATIVE vs R_SPARC_UA32 & unaligned unwind tables - again
- Next message (by thread): R_SPARC_RELATIVE vs R_SPARC_UA32 & unaligned unwind tables - again
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Binutils mailing list