This is the mail archive of the binutils@sourceware.org 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: Can objdump show friendly symbolic function name?


On Tue, 20 Jul 2010, John Reiser wrote:

> >  That's a corner case that I wouldn't be surprised if it wasn't handled at 
> > all -- ...    switching GOTs in the middle of a function is complicated -- ... 
> > alternatively the current GOT pointer can be used to offset against.
> > Either way rather painful.  Then you need to track
> > backward branches to switch back as appropriate, etc., etc.
> 
> One way to handle the overflow is to put a vector of pointers to every GOT_i
> at some fixed offset in each GOT:
> 
>    GOT0: .addr GOT0, GOT1, GOT2, GOT3
> 	...
>    GOT1: .addr GOT0, GOT1, GOT2, GOT3
> 	...
>    GOT2: .addr GOT0, GOT1, GOT2, GOT3
> 	...
>    GOT3: .addr GOT0, GOT1, GOT2, GOT3
> 	...
> Then you don't need to _switch_, you just suffer an indirection
> (another load with delay slot) for outlanders.  For a FETCH to GPR
> the indirection can use the same register as the destination,
> else use $AT as for a STORE.

 Of course, that sounds obvious to me even, but then you wouldn't have the 
problem with decoding <offset>($gp) references concerned here as $gp would 
always point to the same GOT throughout a function.  Note the serious 
performance penalty to access "outlanders", especially on load-delay slot 
platforms.

>  Yes, the compiler must be told
> to generate such code.

 Not quite so -- GAS already does this sort of macro expansion already, at 
least for the MIPS target, as it has to choose between local and global 
symbol references, if nothing else, that may not always be told apart 
until all the file has been assembled -- see how LW and friends are 
implemented.

  Maciej


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