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