[JFerraris]

Hi

I appreciate the response! Hmm, that was what I did think since you guys just have GDB as the underlying tool.

For some reason it doesn’t allow me to step into a function that is allocated to RAM though, and if the whole program is, I just get the 0xdeadbeef stack frame and Source Not Available page.

I will look more at gdb to see if I can deduce the problem too though.

Thank you

[JFerraris]

Hello,

This question is a question about debugging RAM with VisualGDB, it isn’t a project question or anything like that. I was only giving those details to help understand the problem.

Thank you.

[JFerraris]

Wrong post, this one looked almost identical to my most recent hex file generation one.

[JFerraris]

Hello! Thanks for the reply.

I was more looking for what the objcopy command was to generate the hex file, but that turned out not to be a problem for me at all. 🙂

[JFerraris]

Thanks for the response.

Okay that is helpful. I am trying to pull out the hex generation command from the log but I can’t get the log to display the actual command used to generate with objcopy.

Do you happen to know all the arguments that it is passed?

That would make sense if it was using -gap-fill with 0x00…

[JFerraris]

Thank you for pointing me in the right direction! I found this link that explained it all, ninja was the culprit here. To get ninja to not delete the rsp file I used the -d keeprsp switch in the Ninja Options in VisualGDB Properties:

https://gitlab.kitware.com/cmake/cmake/-/issues/20277

Thank you for the help!

Attachments:

You must be logged in to view attached files.

[Author]

Posts