In the mean time, we got basic debugging working. There's one problem left I'm not sure how to solve though. In the DWARF compilation unit header, you have to record the start and the end address of the code in that compilation unit (= object file). We currently do this by inserting a ".text" section at the start of the object file with a start label, and one at the end of the object file with an end label.

On Win32 however, we don't put any code in a plain ".text" section. We put all code is sections called like ".text.n_p$test_proc" and ".text.n__main". The linker script afterwards groups all .text* sections, but it puts the plain ".text" sections first. As a result, all these start and end labels end up at exactly the same location: at the very beginning of the code section of the entire application, rather than at the individual start and end addresses of the code from the individual object files.

I don't immediately see how to fix this. Maybe be we can put those labels at the start and end of the al_procedures assembler lists for Windows, but I don't know whether we never put .text* sections in any other assembler lists.

Jonas

--- From the DRAWF2 spec ----------------------
The compilation unit entry may have the following attributes: 1.A DW_AT_low_pc attribute whose value is the relocated address of the first machine instruction generated for that compilation unit. 2.A DW_AT_high_pc attribute whose value is the relocated address of the first location past the last machine instruction generated for that compilation unit. The address may be beyond the last valid instruction in the executable, of course, for this and other similar attributes. The presence of low and high pc attributes in a compilation unit entry imply that the code generated for that compilation unit is contiguous and exists totally within the boundaries specified by those two attributes. If that is not the case, no low and high pc attributes should be produced.

--- From the DRAWF# spec ----------------------
Either a DW_AT_low_pc and DW_AT_high_pc pair of attributes or a DW_AT_ranges attribute whose values encode the contiguous or non-contiguous address ranges, respectively, of the machine instructions generated for the compilation unit.
A DW_AT_low_pc attribute may also be specified in combination with DW_AT_ranges to specify the default base address for use in location lists and range lists.

------------------------------------------------

If we cannot solve this, in case of DWARF2 i think we can leave those attributes out. And in case of DWARF3 I think we can use ranges to specify each section.

Marc

Marc Weustink wrote

If we cannot solve this, in case of DWARF2 i think we can leave those attributes out.

I've tested this (by editing the .s file) and gdb still seems to work and doesn't complain anymore.

Marc

Marc Weustink wrote on do, 19 mrt 2009:

Can you test the attached patch? I tried to send it to Paul, but mail.ru thought it was spam...

Jonas

---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.

Jonas Maebe пишет:

When I'm at work you can use :)

Best regards,
Paul Ishenin.

Jonas Maebe wrote

> I've tested this (by editing the .s file) and gdb still seems to work > and doesn't complain anymore. Can you test the attached patch? I tried to send it to Paul, but mail.ru

I have tested. No more warnings!

But, it uses external linker anyway now :( Maybe after your patch internal linker will work too? How can I check this?

Best regards,
Paul Ishenin.

Paul Ishenin wrote on do, 19 mrt 2009:

That's extremely unlikely.

How can I check this?

Look for the following code in compiler/options.pas and disable it:

       { the internal linker does not work yet with DWARF either }
       if assigned(target_info.link) and
          not(cs_link_extern in init_settings.globalswitches) then
         begin
           Message(option_dwarf_external_linker);
           include(init_settings.globalswitches,cs_link_extern);
         end;

Jonas

---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.

Jonas Maebe wrote

That's extremely unlikely.

indeed:

C:\1\test>D:\programming\mingw\bin\gdb.exe ptest.exe GNU gdb 6.8
...
Dwarf Error: wrong version in compilation unit header (is 0, should be
2) [in module C:\1\test/ptest.exe]

Best regards,
Paul Ishenin.