Fix and Continue, part 1

Daniel Jacobowitz drow@mvista.com
Sat Mar 8 04:16:00 GMT 2003


On Fri, Mar 07, 2003 at 04:14:01PM -0800, Mike Stump wrote:
> On Thursday, March 6, 2003, at 07:33 PM, Daniel Jacobowitz wrote:
> >Why is this necessary?  I'd think it would be generally easier and less
> >intrusive to just make sure functions were a minimum of (however many
> >instructions) long; if you're overwriting the code, why not overwrite
> >the code instead of a padding buffer?
> 
> The gdb folks here who designed it wanted it that way!  :-)  They face 
> the problem up dating and patching in the new .o files into a running 
> system, its hard enough, and the nops remove some of the hair and make 
> it a bit easier for them to do it.  I don't  have a better answer than 
> that, though, if someone finds a way to make it work, even when the 
> nops aren't there, I'd be happy to remove them.

OK, if it's supposed to work on a running system then that makes sense;
there's a safe way to insert a jump at the beginning of a procedure
given nops and atomic word stores.

> >>There is another set of changes that indirect all global data accesses
> >>through pointers at runtime, so that the newly loaded code will get 
> >>the
> >>old data, instead of any new data.  I'll be submitting that next.
> >
> >Hrm, I can't intuitively see why that's necessary either.  I'm curious,
> >tell me more :)
> 
> Oh, this is far easier:
> 
> int i = 10;
> 
> foo() {
> 	++i;
> }
> 
> and then reload:
> 
> int i = 10;
> 
> foo() {
> 	++i;
> 	printf("%d\n", i);\
> }
> 
> on top of the previous code.  We want the printf to print the `old' i, 
> not the newly loaded i.  If i is 100 in the running program, and we 
> load up the new .o file, we want the next iteration through foo to 
> print 101, not 11.

Hrm... so it's only necessary to use the switch on hot-loaded code,
right?  If so then that more or less makes sense to me.  I'd think
there was a better way but Mach-O might complicate things...

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer



More information about the Gcc-patches mailing list