This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: What is the precise definition of NOTE_INSN_FUNCTION_BEG?


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 :-)


> 
> 
> MM
> 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]