<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>
I am looking at some oddity I found following up
<a class="moz-txt-link-freetext" href="https://forum.lazarus.freepascal.org/index.php/topic,57568.0.html">https://forum.lazarus.freepascal.org/index.php/topic,57568.0.html</a><br>
<br>
Unfortunately, I have no code yet to reproduce it.<br>
I have looked at the generated debug info, as given by objdump.<br>
<br>
file format pei-x86-64<br>
Compilation Unit @ offset 0x0:<br>
Length: 0xa1 (32-bit)<br>
Version: 2<br>
Abbrev Offset: 0x0<br>
Pointer Size: 8<br>
<0><b>: Abbrev Number: 1 (DW_TAG_compile_unit)<br>
<18> DW_AT_producer : Free Pascal 3.2.0 2021/02/21<br>
<br>
The following part of the info looks wrong to me (original names
replaced):<br>
<br>
<1><cef4f>: Abbrev Number: 8 (DW_TAG_subprogram)<br>
<cef50> DW_AT_name : FOO<br>
<cef60> DW_AT_prototyped : 1<br>
<cef61> DW_AT_calling_convention: 65 (user defined)<br>
<cef62> DW_AT_external : 1<br>
<cef63> DW_AT_low_pc : 0x10004a990<br>
<cef6b> DW_AT_high_pc : 0x10004adc4
<<<<<<<<<<<<< NOTE THE END
ADDR<br>
<br>
<1><cefa8>: Abbrev Number: 9 (DW_TAG_subprogram)<br>
<cefa9> DW_AT_name : fin$000000B0<br>
<cefb6> DW_AT_prototyped : 1<br>
<cefb7> DW_AT_calling_convention: 65 (user defined)<br>
<cefb8> DW_AT_low_pc : 0x10004a950<br>
<cefc0> DW_AT_high_pc : 0x10004a988<br>
<br>
<1><cefda>: Abbrev Number: 8 (DW_TAG_subprogram)<br>
<cefdb> DW_AT_name : XYZ<br>
<cefee> DW_AT_low_pc : 0x0
<<<<<<<<<<<<< code not
included, not used/called<br>
<ceff6> DW_AT_high_pc : 0x0<br>
<br>
<1><cf040>: Abbrev Number: 6 (DW_TAG_subprogram)<br>
... Several other DW_TAG_subprogram, with address BEFORE FOO, and
(as far as I checked also line-numbers before FOO.<br>
... I guess those are included here, because they did not get called
before, and the compiler adds the debug info only now ???<br>
... Or could there be other reasons for the out-of-order
inclusion???<br>
<br>
<1><cf812>: Abbrev Number: 8 (DW_TAG_subprogram)<br>
<cf813> DW_AT_name : BAR<br>
<cf822> DW_AT_prototyped : 1<br>
<cf823> DW_AT_calling_convention: 65 (user defined)<br>
<cf824> DW_AT_external : 1<br>
<cf825> DW_AT_low_pc : 0x10004adb0
<<<<<<<<<<<<< NOTE THE START
ADDR<br>
<cf82d> DW_AT_high_pc : 0x10004ae26<br>
<br>
BAR starts within FOO. That seems wrong? (also see the line info
below)<br>
From the code samples I received from the author, this is NOT a
nested proc.<br>
<br>
This (and the line-info) leads to a crash of the app, when run under
gdb, as gdb adjusts the position of breakpoints, and ends setting it
into the middle of an asm instruction. <br>
<br>
According to the author, the crash only happens if there are no
calls to XYZ. Otherwise the crash does not happen. I do not have
info (yet), if the overlapping addresses are present or not, if XYZ
is used.<br>
The inclusion/exclusion of XYZ triggers
<a class="moz-txt-link-freetext" href="https://gitlab.com/freepascal.org/fpc/source/-/issues/38117">https://gitlab.com/freepascal.org/fpc/source/-/issues/38117</a> which
can be seen in the line-info of this app too (i.e. line info
contains none relocated entries that compute to invalid addresses
for those lines).<br>
<br>
<br>
<br>
** The line-info of "FOO"<br>
[0x00011cee] Extended opcode 2: set Address to 0x10004a990<br>
[0x00011cf9] Set column to 1<br>
[0x00011cfb] Advance Line by 2452 to 2453<br>
[0x00011cfe] Copy<br>
[0x00011cff] Advance PC by 37 to 0x10004a9b5<br>
[0x00011d01] Copy<br>
....<br>
[0x00011d5b] Advance Line by -2 to 2453<br>
[0x00011d5d] Copy<br>
[0x00011d5e] Advance PC by 9 to 0x10004ad95<br>
[0x00011d60] Special opcode 22: advance Address by 0 to
0x10004ad95 and Line by 23 to 2476<br>
[0x00011d61] Extended opcode 2: set Address to 0x10004adc4<br>
[0x00011d6c] Extended opcode 1: End of Sequence<br>
<br>
It advances all the way to line 2476 / 0x10004ad95<br>
Then it goes to address 0x10004adc4 (before "End of Sequence")<br>
This is inside of "BAR". <br>
<br>
** The line info shows that the next line (2484) is within the "not
included / not called" proc XYZ<br>
[0x00011d6f] Extended opcode 2: set Address to 0x0<br>
[0x00011d7a] Set column to 1<br>
[0x00011d7c] Advance Line by 2483 to 2484<br>
[0x00011d7f] Copy<br>
[0x00011d80] Advance PC by 13 to 0xd<br>
<br>
<br>
** The line-info of "BAR"<br>
This continues from the line-info of XYZ (as seen by the none
relocated entries)<br>
<br>
[0x00011db8] Special opcode 9: advance Address by 0 to 0x12c and
Line by 10 to 2500<br>
....<br>
[0x00011dc2] Special opcode 0: advance Address by 0 to 0x17c and
Line by 1 to 2504<br>
[0x00011dc3] Advance PC by 80 to 0x1cc<br>
[0x00011dc5] Set column to 1<br>
[0x00011dc7] Special opcode 12: advance Address by 0 to 0x1cc and
Line by 13 to 2517<br>
[0x00011dc8] Extended opcode 2: set Address to 0x0<br>
[0x00011dd3] Extended opcode 1: End of Sequence<br>
<br>
** BAR<br>
[0x00011dd6] Extended opcode 2: set Address to 0x10004adb0<br>
[0x00011de1] Set column to 1<br>
[0x00011de3] Advance Line by 2521 to 2522<br>
[0x00011de6] Copy<br>
[0x00011de7] Advance PC by 21 to 0x10004adc5<br>
[0x00011de9] Set column to 3<br>
[0x00011deb] Special opcode 0: advance Address by 0 to
0x10004adc5 and Line by 1 to 2523<br>
<br>
BAR starts at line 2522 (confirmed by the author).<br>
The address 0x10004adb0 could be correct, as procs should afaik
start at 16 byte boundaries?<br>
<br>
Line 2522 at 0x10004adb0 is an entry in the line info table, made by
the "copy" statement.<br>
<br>
-----------------<br>
So in conclusion something is wrong there.<br>
<br>
As for the GDB crash (2500 is in the dead code, and gdb searches the
next line with code, which we know to be 2522 in BAR):<br>
<span style="left: 104px; top: 345.001px; font-size: 18.3993px;
font-family: serif; transform: scaleX(0.997378);"
role="presentation" dir="ltr"><info line "code1.pas":2500></span><br
role="presentation">
<span style="left: 104px; top: 389.801px; font-size: 18.3993px;
font-family: serif; transform: scaleX(1.00571);"
role="presentation" dir="ltr">~"Line 2500 of \"code1.pas\" </span><span
style="left: 104px; top: 412.201px; font-size: 18.3993px;
font-family: serif; transform: scaleX(0.963034);"
role="presentation" dir="ltr" class="">is at address 0x10004adb0
<FOO> but contains no code.\n"<br>
<br>
GDB found the line, after that I don't know what GDB did exactly<br>
- line 2500 is in XYZ and gdb must have seen the address is not
correct, and ignored it.<br>
- then probably it went to the last good line, and that is the "</span><span
style="left: 104px; top: 412.201px; font-size: 18.3993px;
font-family: serif; transform: scaleX(0.963034);"
role="presentation" dir="ltr" class="">End of Sequence"<br>
=> which would explain "no code" <br>
=> and explain the address found when setting the break<br>
</span><span style="left: 104px; top: 412.201px; font-size:
18.3993px; font-family: serif; transform: scaleX(0.963034);"
role="presentation" dir="ltr" class=""><br>
Setting a breakpoint:</span><br>
<span style="left: 104px; top: 524.201px; font-size: 18.3993px;
font-family: serif; transform: scaleX(1.02444);"
role="presentation" dir="ltr"><-break-insert
"code1.pas:2500"></span><br role="presentation">
<span style="left: 104px; top: 546.601px; font-size: 18.3993px;
font-family: serif; transform: scaleX(1.00992);"
role="presentation" dir="ltr">^done,bkpt={number="37",type="breakpoint",disp="keep",enabled="y",addr</span><span
style="left: 104px; top: 568.801px; font-size: 18.3993px;
font-family: serif; transform: scaleX(0.945405);"
role="presentation" dir="ltr" class="">="0x000000010004adc4",func="FOO",file="code1.pas",</span><span
style="left: 104px; top: 613.601px; font-size: 18.3993px;
font-family: serif; transform: scaleX(0.983842);"
role="presentation" dir="ltr">line="2500",times="0",original-</span><span
style="left: 104px; top: 636.001px; font-size: 18.3993px;
font-family: serif; transform: scaleX(1.01033);"
role="presentation" dir="ltr">location="code1.pas:2500"}</span><br
role="presentation">
<br>
The address <span style="left: 104px; top: 568.801px; font-size:
18.3993px; font-family: serif; transform: scaleX(0.945405);"
role="presentation" dir="ltr" class="">0x000000010004adc4 is
indeed from the "</span>End of Sequence" for "BAR"<br>
<br>
However, if that address is not in BAR (and if BAR ends long
before), then this is <br>
- the address 1 byte before line 2523<br>
- or the address $14 bytes into line 2522 (the last byte of asm code
of that line).<br>
In that case, it is possible that this is not the start of an
asm-instruction, but in the middle of one, and then the app would
crash, after running the modified code (by having $CC somewhere in
the operand part of an asm instruction).<br>
<br>
---------------<br>
---------------<br>
In any case, if the initial part of my analysis is correct then fpc
wrote incorrect address to the dwarf info (both the high/low_pc, and
the "End of Sequence").<br>
<br>
Ideally we need a reproducible example.<br>
But in order to get this, any idea what we are looking at, and
therefore how to strip the original code, so we can get such an
example would be helpful.<br>
<br>
Any comments / ideas?<br>
<br>
<br>
</body>
</html>