This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB 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: [PATCH] Fix that different function breakpoints are set at same pc address (PR gdb/12703)


Hi,

Sorry for bringing this topic back after so long time.
Recently I met a case which I think may have relation with
this topic. Please see my embedded comments and if I am wrong
please correct me.

> Indeed.  Well, GDB is not a compiler; it is supposed to be able to
> debug buggy code.  :-)  Turning things upside down, the root question
> is
> whether there are valid cases where when setting a breakpoint
> at "foo", when GDB goes analysing the prologue, GDB should cross
> function boundaries into the next function, which would get
> broken by Terry's proposal.  E.g., say, foo and bar get merged
> by some smart compiler/linker:
> 
> foo:
>   <nop>
> bar:
>   <regular prologue>
>   <body code>
> 
> I guess setting a break on "foo" should set a breakpoint
> on "<body code>".  Or (another user of prologue skipping,)

I have a bunch of interrupt response functions in my source whose layout looks like:

ext_isr_100:
            nop
ext_isr_101:
            nop
ext_isr_102:
            nop
bar:
     <regular prologue>
     <body code>

If breakpoints of function ext_isr_100, ext_isr_101 and ext_isr_102 are all set on bar's
<body code>. Then I think I have no way to figure out which interrupt is trigged.
For this case, I still think it is better to set breakpoint inside the function body.


> stepping into a foo() call should only stop on "<body code>".
> Or, should GDB be conservative, and never cross the function
> body when skipping the prologue the hard way, and only
> cross it if debug info says so.
> 
> --
> Pedro Alves

Best regards,
Terry





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