Eigen Compiler Suite

My version does not yield an error. Maybe this error was introduced by backporting the compiler? The equality check of binary sections is done in object.cpp while the error is produced in objlinker.cpp.

Btw. the same error is also reported if I declare the section .duplicable.

I don't understand. The section you mentioned is generated by the DWARF debugging information converter and is already duplicable in the object file.

My version does not yield an error.

Unfortunately I cannot test with the original version, since I need the patches to at least come to the issue.

The equality check of binary sections is done in object.cpp

Just checked in the debugger; the difference is in the links field; two of the four links differ at least in name ("_debug_info_unit_/tmp/fileaNj7VM_type5" vs "_debug_info_unit_/tmp/fileaNj7VM_type2", and "_debug_info_unit_/tmp/fileaNj7VM_type7" vs "_debug_info_unit_/tmp/fileaNj7VM_type4").

Where are these names generated?

This was an issue in version 0.0.40 which got fixed in the current one. It seems you are using an old version of dbgdwarfconverter.cpp.

Ok, thanks for the hint; that was very helpful and I was able to fix the issue.

I didn't find the time yet to fully catch up with all 0.0.41 patches, but focused on the ones I thought were important for me; I added dbgdwarfconverter.cpp only recently and didn't compare it to the more recent version at all, which I should have done.

Maybe this is a good opprotunity to point to the type names of basic types shown in dbg. Do you have a hint where the "<invalid type code 8>" comes from and why it occurs? The structured types work well and are correctly displayed; it's just with the basic and pointer to basic types. Here is a screenshot of my debugger:

According to the intermediate code for the function shown above you are only providing basic types for symbol declarations. Basic types are enough to correctly display the value of the corresponding variables in your debugger, but they are anonymous and hence the debugger cannot display a proper type name. For this you need to define type sections and have basic type declarations refer to their names instead:

.code printf
    sym    +60, "format", ptr [$fp + 8]
    ptr
    type    "char" 

    sym    +56, "ap", ptr [$fp - 4]
    type    "valist" 

    sym    +52, "rc", ptr [$fp - 8]
    type    "int" 

.type char
    type    s1

.type int
    type    s4

.type valist
    type    u1

Interesting. I naively thought that since the IR already knows the basic types I don't have to explicitly declare them in the debug info. But apparently it's on contrary: if I use the built-in basic types for symbol declarations then the type doesn't appear in the debugger even if I also declare e.g. ".type s1\ntype s1". But now I changed codegen so that also symbol declarations use my own type names, and then declare these with .type sections, and now the debugger shows them. Problem solved, thanks very much again for your support!

A type definition like .type s1 type s1 does appear in the debugger if that type section name is referenced using a string operand. But that is pretty pointless and confusing: type sections are meant to provide proper names for built-in and user-defined types of the source language, not intermediate code itself. After all, the user declared the variable as char not s1. Consider this example.

I have yet hit a lot of other cases of "unequal duplicate" errors. The text representation of these .type sections look all the same for me, but the linker concludes otherwise.

Please find all cod files of the application attached and all error messages by the linker.

Given e.g. the error "_debug_info_type_som$Interfaces$1f9e73b9b7$ForEachInterface$Class$: error: unequal duplicate" I search for all ".type som$Interfaces$1f9e73b9b7$ForEachInterface$Class$" in the awfy cod files and get five files where this type is declared.

Here what I see in DeltaBlue.cod:

.type som$Interfaces$1f9e73b9b7$ForEachInterface$Class$

    loc    "som.Interfaces.1f9e73b9b7.h", 11, 1
    rec    +14, 8
    field    "super$", 0, ptr 0
    loc    "som.Interfaces.1f9e73b9b7.h", 44, 1
    ptr
    type    "som$Interfaces$1f9e73b9b7$ForEachInterface$Class$" 
    field    "apply", 4, ptr 0
    loc    "som.Interfaces.1f9e73b9b7.h", 45, 1
    ptr
    func    +6
    void
    ptr
    void
    ptr
    ptr
    type    "DeltaBlue$Sym" 

Here what I e.g. see in som.Vector.1f9e73b9b7.cod

.type som$Interfaces$1f9e73b9b7$ForEachInterface$Class$

    loc    "som.Interfaces.1f9e73b9b7.h", 11, 1
    rec    +14, 8
    field    "super$", 0, ptr 0
    loc    "som.Interfaces.1f9e73b9b7.h", 44, 1
    ptr
    type    "som$Interfaces$1f9e73b9b7$ForEachInterface$Class$" 
    field    "apply", 4, ptr 0
    loc    "som.Interfaces.1f9e73b9b7.h", 45, 1
    ptr
    func    +6
    void
    ptr
    void
    ptr
    ptr
    type    "DeltaBlue$Sym" 

But both look identical for me, also the other three. What do I overlook?

I should also mention that I have backported all 0.0.41 changes to my source code version; so the behaviour of my version should be identical to the official one.

You have identified a bug in the debugging information converter which requires some time to fix. Thanks for reporting and sorry for the inconveniences!

Ok, I see. Sorry for giving you more work.

I actually also made another observation with libraries and debugging. If I compile the libc.c and one of the test cases separately and just link the obf and dbf together, I can jump into e.g. printf; but if I create a library of libc.c which includes the dbf (I checked that libc.lib with debugging information is indeed bigger than without), I cannot step into printf. I will set up the files necessary to reproduce both cases.

Interesting. This might have to do with filenames in source code locations which are always treated as relative rather than absolute paths at the moment.

Here is the example.

The attached object_files.tar.gz includes the obf and dbf generated from the source files, but also the lib file alternatively compiled to a library which includes the debug info. In both ways, when I link the 00056.obf with both the libc.obf or libc.lib, the resulting application works and the debugger is able to step into printf showing the right source file.

I also attached a separate libc.lib, which was built in another directory. If I link 00056.obf to this version of libc.lib, the application still works, but I'm no longer able to step into printf.

The effect indeed might be related to relative file names. What mostly surprises in that case is that I actually didn't move the second libc.lib away from the place where it was created, but just passed the absolute path to this libc.lib file to the linker. The linker therefore seems to not consider the location of the lib when looking at the paths included with the lib, but seems to take them verbatim. This essentially forces me to build everything to the same directory. Maybe absolute source path would be more practical. When instead rebasing relative to the object file path there would still be the issue when I move the lib to another directory after build.

Yes, filenames should probably be absolute but I am not quite sure yet which stage should do the translation. The next version will hopefully fix this issue. For the time being, you could compile the library using absolute paths to begin with.

you could compile the library using absolute paths to begin with.

That's what I actually intended; but as it seems, with cparser the absolute path seems to get lost somewhere; I just realized this when comparing the cod files I sent you earlier.

It seems to depend how and from where I run the compiler whether the resulting paths are absolute or relative. That could also fully explain the observed behaviour with libc.lib. I have to do more research on this.

Ok, I now know the reason of the issue, thanks for the hint.

If I assure that the paths fed to the compiler are absolute, the resulting libc.lib can be stepped into by the debugger regardless where it was originally built, and I can even move the lib somewhere else for the build and it still works.

That's all I need, you don't have to change anything apparently.

Not sure why I didn't notice this with chibicc; maybe because it can compile *.c and I never had to deal with libs in the debugger. Cparser, which I'm currently working on, unfortunately cannot compile *.c, which is a bit annoying.

You have identified a bug in the debugging information converter which requires some time to fix.

Apparently cparser produces more accurate type information than chibicc, which is why I only hit the issue now. As a work-around I can prefix all type names with the file hash, so there is no name collision anymore. Seems to work.

This issue has been fixed and will be available in the next version.