view argc and argv in FpDebug

[440bx]

Hello,

I've been trying, unsuccessfully, to view the values of argc and argv while debugging using FpDebug.  When I hover over the names, the little debug window doesn't show their values.  If I attempt to "evaluate/modify" either one, the evaluate/modify window shows an error message stating that it could not find the identifier/variable.

Is there a way to convince the debugger to show the values of argc and argv ?  (in the case of argv it would be nice to get the full array of pointers (0..argc - 1).

Thank you for your help.

PS: using Lazarus 3.1 (fixes) dated 2024-02-13

[TRon]

Are you using rtl with debug info ?

[440bx]

Are you using rtl with debug info ?

I'm not sure what the correct answer to that question is.  Probably not (I would expect the executable sizes to be larger than what I'm getting.)

That said, I know that the addresses of argc and argv are _present_ in the debug (COFF symbol table) information.  I see them using a PE dump program and also see them using IDA pro, i.e,

Code: Text  [Select][+][-]

1. .bss:0000000100014390 U_$SYSTEM_$$_RETURNNILIFGROWHEAPFAILS db ?
2. .bss:0000000100014390                                         ; DATA XREF: sub_100006230+232↑r
3. .bss:0000000100014390                                         ; sub_100006750+18↑r
4. .bss:0000000100014391                 align 20h
5. .bss:00000001000143A0                 public U_$SYSTEM_$$_ARGC
6. .bss:00000001000143A0 U_$SYSTEM_$$_ARGC dd ?                  ; DATA XREF: main:loc_100001BAA↑r
7. .bss:00000001000143A0                                         ; main+4BC↑r ...
8. .bss:00000001000143A4                 align 10h
9. .bss:00000001000143B0                 public U_$SYSTEM_$$_ARGV
10. .bss:00000001000143B0 U_$SYSTEM_$$_ARGV dq ?                  ; DATA XREF: main+1B7↑r
11. .bss:00000001000143B0                                         ; main+2BC↑r ...
12.  

The information is in the COFF symbol table

Code: Text  [Select][+][-]

1.               Entry :  95
2. 5.c49c  [  4]                   Symbol name inline :      0    (false)
3. 6.03a1  [ 18]                          Symbol name : U_$SYSTEM_$$_ARGC
4.  
5. 5.c4a0  [  4]      Symbol name string table offset :    9a7    [FO: 6.03a1]
6. 5.c4a4  [  4]                                Value :   13a0
7. 5.c4a8  [  2]             (1 based) Section number :      5    .bss
8. 5.c4aa  [  2]                                 Type :      0
9. 5.c4ac  [  1]                        Storage class :      2    CLASS_EXTERNAL
10. 5.c4ad  [  1]          Number of auxiliary symbols :      0
11.  
12.  
13.  
14.               Entry :  96
15. 5.c4ae  [  4]                   Symbol name inline :      0    (false)
16. 6.03b3  [ 18]                          Symbol name : U_$SYSTEM_$$_ARGV
17.  
18. 5.c4b2  [  4]      Symbol name string table offset :    9b9    [FO: 6.03b3]
19. 5.c4b6  [  4]                                Value :   13b0
20. 5.c4ba  [  2]             (1 based) Section number :      5    .bss
21. 5.c4bc  [  2]                                 Type :      0
22. 5.c4be  [  1]                        Storage class :      2    CLASS_EXTERNAL
23. 5.c4bf  [  1]          Number of auxiliary symbols :      0
24.  

Objdump shows that neither argc nor argv are in the dwarf sections. 

[TRon]

Objdump shows that neither argc nor argv are in the dwarf sections.

Then that is probably your problem.

But you can probably circumvent that by declaring:

Code: Pascal  [Select][+][-]

1. var
2.   x: integer absolute argc;
3.   y: ppchar absolute argv;
4.  

and set a watch for x and y instead. Not exactly what you asked for but should be able to show you the contents of argc and argv..

edit and yes, you can also name them argc and argv 

[440bx]

But you can probably circumvent that by declaring:

Code: Pascal  [Select][+][-]

1. var
2.   x: integer absolute argc;
3.   y: ppchar absolute argv;
4.  

Good idea and it works.

Thank you.  That gets the job done

I still think the debugger should be able to watch argc and argv without having to "absolute" variables on top of them because their addresses are in the COFF symbol table but, I'm pleased to have a way to inspect the values.

[TRon]

Good idea and it works.

Thank you for the confirmation.

I still think the debugger should be able to watch argc and argv without having to "absolute" variables on top of them because their addresses are in the COFF symbol table but, I'm pleased to have a way to inspect the values.

coff is able to tell the symbol name and most probably the size of these symbols but details about the type of these symbols is something that is part of (actual) debug information. Also reason why disassemblers can't really do anything useful without debug information in a format that they can understand. Ofc some symbol names used, and startup code sequences are generic to certain compilers and can be used to make an educated guess but they also often go wrong on (guessing) the format of the actual contents of a symbol. As far as my understanding goes fpDebug does not understand coff debug information.

[440bx]

Thank you for the confirmation.

My pleasure and thank you for your help.

[ccrause]

I still think the debugger should be able to watch argc and argv without having to "absolute" variables on top of them because their addresses are in the COFF symbol table but, I'm pleased to have a way to inspect the values.

coff is able to tell the symbol name and most probably the size of these symbols but details about the type of these symbols is something that is part of (actual) debug information. Also reason why disassemblers can't really do anything useful without debug information in a format that they can understand. Ofc some symbol names used, and startup code sequences are generic to certain compilers and can be used to make an educated guess but they also often go wrong on (guessing) the format of the actual contents of a symbol. As far as my understanding goes fpDebug does not understand coff debug information.

Yes, fpdebug only understands DWARF.

[440bx]

Yes, fpdebug only understands DWARF.

I wasn't sure if it used the COFF information or not.  Good to have confirmation that it doesn't.

It's a bit unfortunate it doesn't because the COFF symbol table includes information not found in the dwarf sections and, parsing the COFF symbol table is relatively easy.  OTH, no big deal and the solution in this case is quite simple.

ETA:

I just realized that even if FpDebug parsed the COFF symbol table, it wouldn't obtain the variables' size.  IDA Pro figures them out from how they are used in the code, a debugger-only cannot be expected to do that much analysis.

[Thaddy]

Just curious: why argc and argv instead of ParamCount and ParamStr? Afaik they are direct mappings on Windows. (Except shortstring vs AnsiString which is in Objpas)

[marcov]

Windows gives a UTF16 commandline (GetCommandLineW)  that is parsed by the RTLand kept in pointer variables argc/argv for some implementation orthogonality. Argc/argv have no direct OS relevance.

In trunk, a separate wide copy is kept in argvw for unicode purposes. (paramstru).

I don't see much reason to use either of these in user programs , either go to the real OS source (getcommandlinew) or use paramstr(u)/paramcount that directly query these variables.

[Thaddy]

That's what I thought. Tnx for the info on widestrings/unicode16 strings.

[marcov]

See rtl/win/syswin.inc. Note that there are a lot of differences between fixes and trunk in this regard.

http://www.stack.nl/~marcov/mergelogs32/windowscmdline.html

[440bx]

Just curious: why argc and argv instead of ParamCount and ParamStr? Afaik they are direct mappings on Windows. (Except shortstring vs AnsiString which is in Objpas)

I'm just porting some C code that, of course, uses argc and argv. 

My goal in the port was to make the Pascal code as "parallel" to the C code as possible.  Once I have that kind of port working the same as the C code then, I "forward" the code to be "real" Pascal.

The code would actually be a lot simpler using ParamStr but, I'd have to restructure the code which is something I don't want to do in the first pass.  In the second pass, everything goes

That's the reason I'm (temporarily) dealing with argc and argv.

[Thaddy]

Very similar to my approach.