How do I patch my binary

How do I patch my binary

[Marc Khouzam]

Hi,

There is doc section "Patching Programs".  This got me hoping I could somehow 
patch my binary while I was debugging.

My hope was that I could modify the source code (outside of GDB), recompile 
the binary and have GDB load and use the new binary, without having to restart 
the program.  I couldn't get this to work (using 'set write on' and reloading
the new binary).

When the doc says "Patching" does it mean I actually have to modify the memory
where the code is written, using GDB commands?  Or can I do it high-level
like I originally hoped.

Thanks

Marc





 

Re: How do I patch my binary

[Baurzhan Ismagulov]

On Tue, Nov 23, 2010 at 04:31:22PM -0500, Marc Khouzam wrote:
> My hope was that I could modify the source code (outside of GDB), recompile 
> the binary and have GDB load and use the new binary, without having to restart 
> the program.  I couldn't get this to work (using 'set write on' and reloading
> the new binary).

I don't think you can.

Which platform?

With kind regards,
-- 
Baurzhan Ismagulov
http://www.kz-easy.com/

Re: How do I patch my binary

[Pedro Alves]

On Tuesday 23 November 2010 21:31:22, Marc Khouzam wrote:

> There is doc section "Patching Programs".  This got me hoping I could somehow 
> patch my binary while I was debugging.
> 
> My hope was that I could modify the source code (outside of GDB), recompile 
> the binary and have GDB load and use the new binary, without having to restart 
> the program.  I couldn't get this to work (using 'set write on' and reloading
> the new binary).

Doesn't work that way.  You make it sound like you want edit&continue, which
GDB doesn't do (or rather the toolchain doesn't, since it requires coordination
between the compiler/linker/debugger).  For some extremely lucky scenarios, against
simple remote targets, you might be able to get around with "load", but forget I
said that.

> When the doc says "Patching" does it mean I actually have to modify the memory
> where the code is written, using GDB commands?  

Yes.

> Or can I do it high-level like I originally hoped.

No.

-- 
Pedro Alves

RE: How do I patch my binary

[Marc Khouzam]

> -----Original Message-----
> From: gdb-owner@sourceware.org 
> [mailto:gdb-owner@sourceware.org] On Behalf Of Baurzhan Ismagulov
> Sent: Tuesday, November 23, 2010 4:50 PM
> To: gdb@sourceware.org
> Subject: Re: How do I patch my binary
> 
> On Tue, Nov 23, 2010 at 04:31:22PM -0500, Marc Khouzam wrote:
> > My hope was that I could modify the source code (outside of 
> GDB), recompile 
> > the binary and have GDB load and use the new binary, 
> without having to restart 
> > the program.  I couldn't get this to work (using 'set write 
> on' and reloading
> > the new binary).
> 
> I don't think you can.
> 
> Which platform?

Linux x86.

I'm trying to do with C/C++ the hot-swap that Java allows.

So, if GDB can't do it on its own, can we involve the compiler/linker
to make this happen?  Is there more complexity with C/C++ than with Java?

The section below of the doc talks about patching, but doesn't describe
a way to actually do it :-)
http://sourceware.org/gdb/current/onlinedocs/gdb/Patching.html#Patching

Thanks

Marc

Re: How do I patch my binary

[Baurzhan Ismagulov]

On Wed, Nov 24, 2010 at 10:00:39AM -0500, Marc Khouzam wrote:
> Linux x86.
> 
> I'm trying to do with C/C++ the hot-swap that Java allows.
> 
> So, if GDB can't do it on its own, can we involve the compiler/linker
> to make this happen?  Is there more complexity with C/C++ than with Java?
> 
> The section below of the doc talks about patching, but doesn't describe
> a way to actually do it :-)
> http://sourceware.org/gdb/current/onlinedocs/gdb/Patching.html#Patching

I'm not an expert at that. I've tried set write on, then p *(unsigned
long *)0x8049a5c = 0x4e5f068 -- this does change the value, albeit x/2x
0x08049a57 issued after that shows a bit different value.

If you share the motivation and the details about the extent of the
modifications you want to make, perhaps someone could suggest another
way to do that.

With kind regards,
-- 
Baurzhan Ismagulov
http://www.kz-easy.com/

Re: How do I patch my binary

[Jan Kratochvil]

On Wed, 24 Nov 2010 16:00:39 +0100, Marc Khouzam wrote:
> So, if GDB can't do it on its own, can we involve the compiler/linker
> to make this happen?  Is there more complexity with C/C++ than with Java?

http://www.opensource.apple.com/tarballs/gdb/gdb-1472.tar.gz
/* APPLE LOCAL fix-and-continue */
src/gdb/fix-and-continue.c

Howdy from Apple; Fix and Continue implemented Yet Again
http://sourceware.org/ml/gdb/2003-06/msg00500.html


Regards,
Jan

RE: How do I patch my binary

[Marc Khouzam]

On Thu, 25 Nov 2010,  Jan Kratochvil wrote:

> On Wed, 24 Nov 2010 16:00:39 +0100, Marc Khouzam wrote:
> > So, if GDB can't do it on its own, can we involve the compiler/linker
> > to make this happen?  Is there more complexity with C/C++ than with Java?
> 
> http://www.opensource.apple.com/tarballs/gdb/gdb-1472.tar.gz
> /* APPLE LOCAL fix-and-continue */
> src/gdb/fix-and-continue.c
> 
> Howdy from Apple; Fix and Continue implemented Yet Again
> http://sourceware.org/ml/gdb/2003-06/msg00500.html

This is awesome!  Thanks Jan!

From the email description, this seems to be exactly what I was looking for.
It allows the user to recompile a program, as any other compilation is done, 
and ask GDB to patch it in.

The email mentions that this feature works with the IDE.  But it also
gave me the impression that you could edit with emacs/vi, recompile with GCC
from a shell, and then give GDB the 'fix and continue' command.  To me, that
fits very well with GDB and would have not outside dependencies.
(Of course, I would add this support in Eclipse, but that is not a requirement
for GDB).

From the email:
"Fix and continue is a feature implemented by many other debuggers:
[...]  Sun Workshop, SGI ProDev WorkShop, Microsoft's Visual Studio,
HP's wdb, and Sun's Hotspot Java VM all provide this feature in one way or another"

I don't know enough about GDB to be able to port the feature myself.
I wonder if anyone else in the community would be interested in 
porting this feature?

I think this would be a really nice addition to FSF GDB.

Here is the XCode doc about Fix and Continue which explains it nicely for a user:
http://developer.apple.com/library/mac/#documentation/DeveloperTools/Conceptual/XcodeDebugging/230-Modifying_Running_Code/modifying_running_code.html

Thanks

marc

Re: How do I patch my binary

[Jonas Maebe]

On 25 Nov 2010, at 15:16, Marc Khouzam wrote:

> Here is the XCode doc about Fix and Continue which explains it  
> nicely for a user:
> http://developer.apple.com/library/mac/#documentation/DeveloperTools/ 
> Conceptual/XcodeDebugging/230-Modifying_Running_Code/ 
> modifying_running_code.html

Note that in the mean time that functionality has been deprecated by  
Apple, and may even have already been completely removed from the  
latest Xcode releases. It also never worked that well (hence the  
deprecation, I guess).


Jonas

Re: How do I patch my binary

[Stan Shebs]

On 11/25/10 6:42 AM, Jonas Maebe wrote:
>
> On 25 Nov 2010, at 15:16, Marc Khouzam wrote:
>
>> Here is the XCode doc about Fix and Continue which explains it nicely 
>> for a user:
>> http://developer.apple.com/library/mac/#documentation/DeveloperTools/Conceptual/XcodeDebugging/230-Modifying_Running_Code/modifying_running_code.html 
>>
>
> Note that in the mean time that functionality has been deprecated by 
> Apple, and may even have already been completely removed from the 
> latest Xcode releases. It also never worked that well (hence the 
> deprecation, I guess).

One of the critical aspects to making it work was that all references 
were dynamic and indirected, so that everything could end up in 
different locations after the fix and yet still be found when you 
resumed execution.  But that meant special compiler flags, and more 
differences between "development" and "production" code. (I note the 
contemporaneous discussion about compiler options for Linux.)

In the generic Linux/ELF/ABI etc context, I think it's going to be even 
harder to make it work reliably enough for users to trust.  Certainly it 
was disappointing at Apple, to have put forth the coordinated effort and 
then not seen much uptake.

Stan