Re: Gdb and assignment statements

[Art Berggreen]

Michael Elizabeth Chastain wrote:
> Kevin Buettner wrote ...
> > I'm having trouble understanding why you wish to set a breakpoint on a
> > line that the compiler has optimized out as being a nop.
> 
> I see it like this: htons() on *some* platforms is an identity mapping.
> But this is an implementation detail, and it is opaque to the application
> programmer.
> 
> So it is reasonable to write:
> 
>   port = htons(port);
> 
> .. and it is also reasonable to try to set a breakpoint there.
> Conceptually, something is happening to "port".  Whether something happens
> to its physical bits depends on whether the machine is big-endian
> or little-endian.

You certainly want the macros if you want portable code between
different endianess machines.  You just need to be aware that the code
generated for those machines may optimize very differently.

> > If line 6 (after macro expansion) is really ``port = port;'', what are
> > you going to learn by stopping on line 6 that you can't learn by stopping
> > on line 7?
> 
> I agree.  gdb is a little surprising but it is correct, and I think gdb
> is doing the best that it can.

All breakpoint mechanisms are associated with some particular generated
machine instruction, and not the line of the source code that caused
it.  If something is optimized out, there is NO way to get GDB to break
point on that source line.  The best it can do is set the breakpoint on
the next machine instruction generated (which is often another source
line).

> It's just one more thing to learn about C: that some code expands out
> to nothing and gets optimized away.  On big-endian architectures,
> htonl/htons/ntohl/ntohs can be optimized like this.

Code optimized away isn't hard to get used to.  Debugging highly
optimized code, especially where instruction scheduling has interleaved
the machine instruction sequences of two or more source lines, gets REAL
challenging!

Art