[fpc-devel] Win32 DWARF problem (was: Debugger for FPC)

[Marc Weustink]

Jonas Maebe wrote:
> 
> On 14 Mar 2009, at 15:42, Paul Ishenin wrote:
> 
>> Tomas Hajny wrote:
>>> Keeping -gl instead of -gw?
>>>
>> Sorry, "leave out" was not in my head dictionary :)
>>
>> c:\programming\fpc\bin\i386-win32\ppc386.exe -gw test.pp
>>
>> (gdb) break test.pp:8
>> invalid dwarf2 offset 4243567
> 
> 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.

--- 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