On 30/04/19 22:48, Jeff Law wrote: > On 4/30/19 11:24 AM, Matthew Malcomson wrote: >> On 30/04/19 18:01, Jeff Law wrote: >>> On 4/30/19 10:48 AM, Matthew Malcomson wrote: >>>> Hi Jeff, >>>> >>>> On 30/04/19 16:29, Jeff Law wrote: >>>>> On 1/4/19 9:03 AM, Matthew Malcomson wrote: >>>>>> Hi there, >>>>>> >>>>>> I'm trying to figure out precisely what NOTE_INSN_FUNCTION_BEG means and >>>>>> hoping someone here knows. >>>>> It doesn't mean very much anymore. I believe it was used to >>>>> distinguish between stuff like copying incoming arguments into pseudos >>>>> and real user code. >>>>> >>>>> However, in a world with instruction scheduling and other code motion it >>>>> just doesn't have much use because it's so imprecise, particularly as we >>>>> get deeper into the RTL pipeline. >>>>> >>>> >>>> Ah, I guess an imprecise marker probably needs an imprecise definition ;-) >>>> >>>>>> >>>>> Well, the question I'd ask is precisely what are you trying to mark? >>>> >>>> >>>> I'm wanting to mark the first instruction from "user code". >>>> I'm trying to fix PR88432, where gdb puts the breakpoint from the >>>> "start" command in the wrong place. >>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88432 >>>> >>>> Gdb breaks on the second debug line entry in a function, which in >>>> practice is the instruction directly after NOTE_INSN_FUNCTION_BEG. >>>> >>>> >>>> The "fuzzy" definition from gccint.info didn't seem to explain what was >>>> to happen with compiler inserted code that was not part of the prologue, >>>> and this was what I was hoping to nail down. >>>> >>>> When looking, it seemed the note was being used in three slightly >>>> different ways (I went into more information in the cover letter of my >>>> [RFC] patch https://gcc.gnu.org/ml/gcc-patches/2019-01/msg00543.html ), >>>> and I was hoping to get a precise definition so I could decide what >>>> approach to take. >>> ISTM that we should place the stack protector bits before the >>> NOTE_INSN_FUNCTION_BEG. At least in the non-optimizing compile case >>> that should make the right thing happen. >>> >>> Jeff >>> >> >> Yeah, unfortunately I saw that moving that note would break some other >> places -- where the note is used as a marker for where to insert some >> other code. >> >> The one I can remember (sort of) was that asan stack protection code is >> inserted just before "parm_birth_insn" (which is >> NOTE_INSN_FUNCTION_BEG), and that needs to be done before the non-local >> goto save area as per the solution for bugzilla 88186. >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81186 >> >> That was why I ended up suggesting multiple notes -- it's currently >> trying to satisfy more than one criteria and they're not quite compatible. > Well, we obviously have to keep arg setup, asan, stack protector and > nonlocal stuff in the same relative order, but I believe they should all > ultimately land before the NOTE_INSN_FUNCTION_BEG. THe question is how > to make that happen :-) >
It's pretty easy if we can replace the uses of NOTE_INSN_FUNCTION_BEG with another note: In order to satisfy how it's used in `final_start_function_1`, `sjlj_emit_function_enter` in except.c and the nonlocal stuff I could add a differently named note at the current position. Then I could move NOTE_INSN_FUNCTION_BEG to after everything automatically added since it's then only used by the debug information. How would you feel about a modification of my RFC patch https://gcc.gnu.org/ml/gcc-patches/2019-01/msg00543.html , where the uses of the suggested NOTE_INSN_DEBUG_FUNCTION_BEG are satisfied by NOTE_INSN_FUNCTION_BEG and a new NOTE_INSN_VAR_END where the current NOTE_INSN_FUNCTION_BEG is?
