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. MM