Breakpoint in unused function is moved to another function

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Breakpoint in unused function is moved to another function

1,488 Views
scottm
Senior Contributor II

Running MCUX 10.2.0 - and this time it's a completely fresh, unmodified install with no PEx or non-standard toolchain.

I'm debugging my USB descriptor handling code and set a breakpoint in USB_Desc_Valid_Configation().  (You can tell it's from a Freescale example because 'configuration' is misspelled.  Along with 'composite', 'function', 'is', 'successful', 'received', 'supported', 'increase', 'interface'...)  I forgot, however, that the function isn't actually referenced.  Nor is the next function.

The result is that the breakpoint invisibly moves to an entirely different function further down.  I understand that picking the next line that actually produces any code is typical, but shouldn't it be confined to a single function?  And I seem to remember that CodeWarrior would visibly move the breakpoint marker to its actual location.

Scott

Labels (1)
0 Kudos
Reply
5 Replies

1,281 Views
lpcxpresso_supp
NXP Employee
NXP Employee

I have duplicated the behaviour you describe - and of course, this does raise an interesting question as to how a source line should ultimately be related to an address. For this question, CDT, the Compiler/Linker/Dwarf debug tables and GDB are involved.

However, the behaviour is that breakpoints set by double clicking within the edit view will be set to an address corresponding to the closest match to actual code. You can see within the Debugger console which particular breakpoint has been hit  - if required.  There are alternative options such as setting breakpoints within the IDE on particular functions etc.

You can also drop to the Debugger Console to directly set breakpoints on an address or on a function e.g.

break *0x2000
Breakpoint 6 at 0x2000

break *used_function
Breakpoint 7 at 0x8ac: file ../source/hello_world.c, line 86.

break *unused_function
Breakpoint 8 at 0x0  <<-- since this function doesn't get linked into the image

While we accept that this may not always be ideal, there is likely nothing we can do to change this behaviour.

Yours,

MCUXpresso IDE Support

0 Kudos
Reply

1,281 Views
Alice_Yang
NXP TechSupport
NXP TechSupport

Hi Scott,

Could you please take screenshots show your problem ?

mainly about "The result is that the breakpoint invisibly moves to an entirely different function further down. "

BR

TIC

0 Kudos
Reply

1,281 Views
scottm
Senior Contributor II

pastedImage_3.png

Here is a simplified example.  Note that the breakpoint is set in unused_function(), but the debugger stops on used_function() despite no breakpoint marker showing up there.

Scott

0 Kudos
Reply

1,281 Views
Alice_Yang
NXP TechSupport
NXP TechSupport

Hi Scott,

If place a breakpoint in the function that not called, the breakpoint will fall through to the nexet valid line.

0 Kudos
Reply

1,281 Views
scottm
Senior Contributor II

Yes, that's exactly what I'm trying to illustrate here.  I know what it's doing.  But why?  How could that ever be the intended behavior, having execution stop in an entirely unrelated function?  It tells you nothing about the program flow and gives you no indication of which breakpoint actually caused the break.

0 Kudos
Reply