debug50 seems broken once again for C++ Files

[stephendgilbert]

I'd like to reopen issue #16 again. After it was fixed it worked throughout the fall semester. I'm setting up now for Spring and I noticed that it was broken once again. To replicate the problem.

1. Create chello.c and cpphello.cpp (both just "hello world")
2. make chello and make cpphello (I've added CXXFLAGS to the environment, mimicing the CFLAGS the CS50 IDE sets)
3. Both are runnable and debuggable with gdb
4. debug50 chello works, but debug50 cpphello does not.

Skipping make and using the simplest command line: g++ -O0 -ggdb3 cpphello.cpp -o cpphello did not help. Neither did changing to clang++, or adding the -gdwarf-4 flag on either command.

I thought maybe this was a change made to dwarfdump which is being used to find the executable program name, in the function get_source_files, which invokes dwarfdump.

So, I compiled both a C and C++ program, using both clang and g++ and looked at them with dwarfdump. In C, everything looked normal, but in the smallest C++ file, dwarfdump produced literally hundreds of lines with DW_AT_decl_file. Literally all of the include files in the entire library. However, if I changed the dwarfdump line so that it filtered only DW_AT_name, it worked correctly for both C and C++ with both clang and gcc compilers.

Of course, any changes I make on my own codespace aren't persistent, so it would be nice to get that fixed for my students again.

[rongxin-liu]

Thanks for reporting. Did you experiment with the above in the Codespace environment? @stephendgilbert

I tried compiling a simple cpphello.cpp program like the one you proposed and run dwarfdump on it, but I was getting:

$ dwarfdump cpphello

.debug_info

.debug_str

.debug_aranges

.debug_frame is not present

[stephendgilbert]

Hi, I need to apologize. I've spent another couple hours working on it. I actually did it a couple of different ways a) on a codespace using the CS50 devcontainer and b) directly from code.cs50.io. When I rebuilt both containers, the problem went away for the simple example I posted in my bug report. The problem persists when their projects link to a static library. When I dump the final executable, there are actually several .cpp file names in the dwarfdump, only one of which is in the folder in which the student is working.

I'm going to go ahead and close this. Again, sorry.
--Steve