Joel,

I did the same thing for Apple's gdb, and for the same reasons you 
mentioned.  The solution for the GUI is still not perfect, because you 
end up either moving the breakpoint indicator on them, or you end up 
stopping at the breakpoint but having the PC marker not be where the 
breakpoint marker is, both of which are a little disconcerting.

Another strong reason for doing this in a GUI is if you are using 
varobj's to represent variables.  The reason for this is that the 
varobj stores the frame in which it is valid when it is made.  If you 
stop at the beginning of the function and make varobj's for all the 
local variables (which is the usual mode for a GUI) then the frame that 
is recorded will be the frame of the previous function ('cause the 
frame pointer hasn't been moved yet).  When you then step into the 
function, all the varobj's are now out of scope.  Oops...  At which 
point somebody needs to be smart enough to guess what has happened, 
trash all the varobj's and recreate them in the current scope.  Not a 
very good way to go.

I solved the problem a little differently, however.  The fact is that 
decode_line_1 takes a funfirstline argument, which is supposed to tell 
it whether to move the breakpoint past the prologue.  But it doesn't 
look at this argument in the case of setting a file:line breakpoint.  
So I just made it do that.  I like this solution, because it unifies in 
concept the breakpoint moving done for function symbols and for 
file:line symbols (though as you see, the actual motion is handled by 
different pieces of code.)

I attached that patch below.