Skip to content


Why use foo(void) instead of just foo() – Why void in parameter list

In older C (pre ANSI), the way to declare and define a function is:


int test();

.....

int test(param1, param2)
int param1, param2;
{
    // body of function
}

Current C/C++ still allow this kind of definition (try it out!), which means that if you specified int test(), it actually means test() with unspecified number of arguments (pending parsing when the compiler sees the actual definition of the function).

On a side note, if you did try using the old declaration and definition, notice that the compiler no longer performs type checking (so you can call the function with whatever arguments), and if you used the wrong arguments the program fails at runtime.

Posted in C/C++. Tagged with .

Multi-line string literals in C/C++

Just a quick note, both are valid ways of defining multi-line string, the 1st way is probably preferred as you can indent your strings

const char* str1 = "This "
     "is"
  "a "
"sentence";

const char* str2 = "This \
is\
a \
sentence";

void main() {

printf("%s\n", str1);
printf("%s\n", str2);

}

Posted in C/C++. Tagged with , , .

Visual Studio expand tabs and remove trailing spaces

Expanding tab:
Tools -> Options -> Text Editor -> All Languages -> Tabs

Removing trailing spaces:
Thanks to this post

Tools -> Macros -> Macro Explorer

Under MyMacros there is a macro called EnvironmentEvents, go into it, and inside
“Public Module EnvironmentEvents”, add the following:

Private Sub DocumentEvents_Documents(ByVal document As EnvDTE.Document) _
                                     Handles DocumentEvents.DocumentSaved
    Try
        ' Remove all the trailing whitespaces.
        If vsFindResult.vsFindResultReplaced = _
            DTE.Find.FindReplace( _
                            vsFindAction.vsFindActionReplaceAll, _
                            "{:b}+$", _
                            vsFindOptions.vsFindOptionsRegularExpression, _
                            "", _
                            vsFindTarget.vsFindTargetFiles, _
                            document.FullName, , _
                            vsFindResultsLocation.vsFindResultsNone) Then
            document.Save()
        End If
    Catch ex As Exception
        MsgBox(ex.Message, MsgBoxStyle.OkOnly, "Trim Whitespace exception")
    End Try
End Sub

Posted in Technology. Tagged with , , .

Writing a debugger mini series: A GUI source code viewer, Load, Wrap, Select, Highlight, Scroll and Center vertically on RichEdit (C/C++)

This is a side topic from the Debugger mini series. The debugger is a Windbg extension (because the debuggee is kernel). The goal is to write a simple source code browser in a GUI window that would display source code while you work on windbg’s main window.

I’m going to outline below how to do that (roughly, the code is below draft standard).

1. Create a thread for the UI. This is necessary because you need a dedicated loop to process window messages


DWORD WINAPI uiThread(LPVOID lpParam)
{
    // You need to load the richedit dll before using it
    LoadLibrary(TEXT("Riched32.dll"));
    
    // stuff needed for creating a Windows window
    WNDCLASS wndClass;
    HWND hWnd = 0;
    MSG msg;
    BOOL hasMsg;
    LPVOID lpMsgBuf;
    static BOOL registeredWindow = FALSE;

    if(!registeredWindow) {
        // regsiter the window class
        memset (&wndClass, 0, sizeof(wndClass));
        wndClass.cbWndExtra    = 4;
        wndClass.hCursor       = LoadCursor( NULL, IDC_ARROW );
        wndClass.hIcon         = LoadIcon(GetModuleHandle(NULL), MAKEINTRESOURCE(IDI_APPLICATION));
        wndClass.hInstance     = GetModuleHandle(NULL);
        wndClass.lpfnWndProc   = WndProcFlcndbg;
        wndClass.lpszClassName = TEXT("FlcndbgCodeWindow");
        wndClass.style         = CS_HREDRAW | CS_VREDRAW;
        if(!RegisterClass(&wndClass))
        {
            // decode the error message from GetLastError()
            wndClass.lpfnWndProc = NULL;
            FormatMessage(FORMAT_MESSAGE_ALLOCATE_BUFFER |
              FORMAT_MESSAGE_FROM_SYSTEM |
              FORMAT_MESSAGE_IGNORE_INSERTS,
              NULL,
              GetLastError(),
              MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT), // Default language
              (LPTSTR) &lpMsgBuf,
              0,
              NULL);

            MessageBoxA(NULL, (LPCTSTR)lpMsgBuf, "Error", MB_OK | MB_ICONINFORMATION);
            // Free the buffer.
            LocalFree(lpMsgBuf);

            return 0;
        }
        registeredWindow = TRUE;
    }

    // create the window
    hWnd = CreateWindow(TEXT("XXXXX"), TEXT("XXXXX"),
                WS_BORDER | WS_CAPTION | WS_POPUP,
                50, 50, 600, 600, NULL, NULL, wndClass.hInstance, 0);
    if(!hWnd)
    {
        MessageBoxA( NULL, "Invalid hWnd", "Error", MB_OK | MB_ICONINFORMATION );
        if (wndClass.lpfnWndProc) {
            UnregisterClass(wndClass.lpszClassName, wndClass.hInstance);
        }
        return;
    }

    // display the window
    ShowWindow(hWnd, SW_NORMAL);
    UpdateWindow(hWnd);

    while(1) {
        // process Window messages
        hasMsg = GetMessage(&msg, NULL, 0, 0);
        if(hasMsg)
        {
            TranslateMessage(&msg);
            DispatchMessage(&msg);
        }
    }
}

2. Create the thread

// variables required for thread
HANDLE uiH;
DWORD uiId;

// open a window to display source code (this has to be recreate each time we
// re-enter the debugger (otherwise it would freeze anyway since the message queue
// isnt being processed when this debugger isnt running
uiH = CreateThread(NULL, 0, uiThread, NULL, 0, &uiId);
if(uiH == NULL) {
    // error creating thread
}

3. To communicate with the thread (such as telling it to terminate cleanly, sending it commands like what source to load etc) is another matter not discussed here. But you can look up how to pass messages between threads

4. Creating the Message handlers for the new Window + creating a RichEdit text box for doing the source displaying stuff

HWND childWin;

LRESULT CALLBACK WndProcFlcndbg(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam)
{
    switch(message)
    {
    case WM_CREATE:
        // find the inner area of the window
        GetClientRect(hWnd, &r);

        // create a RichEdit v1 text box with ID 1, fill the entire window
        childWin = CreateWindow(TEXT("RichEdit"), TEXT("Hello?"),
            // Google these flags to see what they do if you are interested
            WS_VISIBLE | WS_CHILD | WS_BORDER | ES_MULTILINE | ES_READONLY | WS_VSCROLL | WS_HSCROLL,
            // random sizes as examples
            0, 0, r.right, r.bottom,
            hWnd, (HMENU) 1, NULL, NULL);
        break;

    default:
        break;
    }
    // default handler for handling all the messages that we did not handle explicitly above
    return DefWindowProc(hWnd, message, wParam, lParam);
}

5. Actually using the RichEdit. I think this is by far the most annoying, and you should avoid using it if at all possible. There are alternatives like the MFC and WPF classes that are much better. Here I do not have a choice due to toolchain constraints…

I will describe here a list of messages that can be used to load text, highlight a line of text, and scrolling the editor to center on the line of text. The code below are not compilable examples and most variable names are pretty bad.

A note here is the variable CHARFORMAT2 cformat; needs to be outside of function scope, because SendMessage returns immediately and cformat may be destroyed before the message is actually processed (if this happens then the color is simply not set).

// the line of text we will be loading
char* lines = "This is a text\nlets see if this new line comeskljdasjdhkjaldhlkasdhgklajdhgaljsdhg up\n\nline 3\nline4\n\n\nline 3\nline4\n\n\nline 3\nline4\n\n\nline 3\nline4\n\nline4\n\n\nline 3\nline4\n\n\nline 3\nline4\n";
// character position thats needed for various messages
int lineChar;
// holder
int len;
// holds the line # for the top most visible in the editor
int topLine;
// the line # for the current selected line
int thisLine;
// bottom most line # that is visible
int bottomLine;
// total line # in the editor
int lastLine;
// # of lines to scroll
int scroll;
// direction of scroll
int scrollDir;
// tmp
int i;
// for getting the rectangle area of the text editor
RECT r;
// required by some messages
POINTL p;
// for setting the color of the current line of text
CHARFORMAT2 cformat;

// load text into the editor
SendMessage(childWin, WM_SETTEXT, NULL, lines);

// disable line wrap, see http://ucla.jamesyxu.com/?p=238
SendMessage(childWin, EM_SETTARGETDEVICE, NULL, 1);

// here we arbitrarily try to get the editor to scroll to line # 15, highlight it with red background and place that in the middle of the editor        
// what is the character # for the first char on line 15?
lineChar = SendMessage(childWin, EM_LINEINDEX, 15, 0);
// what is the length of the line at 15?
len = SendMessage(childWin, EM_LINELENGTH, lineChar, 0);
// select line 15 (by selecting the first char + len        
SendMessage(childWin, EM_SETSEL, lineChar, lineChar+len);
// set color
cformat.dwMask = CFM_BACKCOLOR;
cformat.cbSize = sizeof(cformat);
cformat.crBackColor = RGB(255,0,0);
SendMessage(childWin, EM_SETCHARFORMAT, SCF_SELECTION, &cformat);
// scroll to selection (so it is at least on screen)
SendMessage(childWin, EM_SCROLLCARET, 0, 0); 

// compute how many lines we need to scroll to adjust the target line to the middle (vertically)
topLine = SendMessage(childWin, EM_GETFIRSTVISIBLELINE, 0, 0);
thisLine = SendMessage(childWin, EM_LINEFROMCHAR, lineChar, 0);
// the way to get the last visible line on RichEdit is weird:
SendMessage(childWin, EM_GETRECT, 0, &r);
p.x = r.right;
p.y = r.bottom;
bottomLine = SendMessage(childWin, EM_CHARFROMPOS, 0, &p);
bottomLine = SendMessage(childWin, EM_LINEFROMCHAR, bottomLine, 0);
// last line of the file
lastLine = SendMessage(childWin, EM_GETLINECOUNT, 0, 0);

// We want thisLine to be the center of the screen.
// bottomLine - topLine / 2 is the target line, with a initial offset of topLine #
scroll = thisLine - ((bottomLine - topLine)/2) - topLine;

printf("Top is: %d, Bottom is %d, this is %d, scroll %d\n", topLine, bottomLine, thisLine, scroll);

// find the scroll direction
if (scroll > 0)
    scrollDir = SB_LINEDOWN;
else
    scrollDir = SB_LINEUP;
//  do the actual scroll
for(i = 0; i<abs(scroll); i++)
{
    SendMessage(childWin, WM_VSCROLL, scrollDir, 0);
}

Posted in C/C++, Debugger. Tagged with , , , , , , , .

C/C++ RichEdit turn off line wrap

When you create a RichEdit (with CreateWindow for example), the default behavior includes line wrap. But there doesnt seem to be an option to turn that off.

The solution is random as well:

  • Turn off Line wrap: SendMessage(childWin, EM_SETTARGETDEVICE, NULL, 1);
  • Turn on Line wrap: SendMessage(childWin, EM_SETTARGETDEVICE, NULL, 0);

Posted in C/C++. Tagged with , , .

Mini series on writing a source level debugger for microcontrollers (How to build a debugger)

So as you may have seen from the post on DWARF-2 debug_frame that I am building a debugger for a sub processor (RISC like instructions).

Throughout the process of trying to build the debugger, I have found that there are not a lot of information online on the history of debuggers and how to build them. The popular few are about using linux or windows provided capabilities like pTrace, /proc/ and DebugEngine.

I will be writing a small series on how to build a debugger from scratch, with focus on micro controllers and sub processors (my is for inside a GPU, hint hint).

Please checkout Eli Bendersky’s articles on debuggers and how they work. This is a fantastic set of blog posts.

Posted in Debugger. Tagged with .

Decoding .debug_frame information from DWARF-2

DWARF2 contains .debug_frame information for helping debuggers figure out how to unwind frames (i.e. how to restore the stack to the previous frame from any instruction executing using the current frame.

Unfortunately there isn’t a lot of information online that actually shows (in a simple enough manner for someone new like me) to understand easily how it is decoded.

Below, I will attempt to provide information comprehensive enough to understand the .debug_frame section of the DWARF-2, it is a good thing that this section is meant to be stand alone, so not much other understanding is required.

**This is meant to be a hands on step-by-step introduction to .debug_frame, aimed at enabling the reader to start reading more complex ones after the example**

Things you will need:

  1. This article assumes understanding of general debugging knowledge such as ELF structure, various debugging sections of DWARF, using binutils etc.
  2. Standard document of DWARF-2 and DWARF-3
  3. On DWARF-2 standard, skim through Section 6.4: Call Frame Information (don’t worry if nothing make sense, just read it so you know what’s included)
  4. Open Appendix 5 of DWARF-2 standard and Appendix D.6 of DWARF-3 standard.

So we are ready to go, notice that Appendix 5 and Appendix D.6 of the two standards are really similar, and that is because for the most part they are the same.


Basic Idea

The basic idea of the .debug_frame is to allow you to figure out how to restore all the registers to the previous frame on the stack, from any instruction of the current frame. For example, consider the following assembly (with C code inline – objdump -S):


int testCall()
{
4004cc: 55 push %rbp
4004cd: 48 89 e5 mov %rsp,%rbp
int xyz = 25;
4004d0: c7 45 fc 19 00 00 00 movl $0x19,-0x4(%rbp)

xyz++;
4004d7: 83 45 fc 01 addl $0x1,-0x4(%rbp)

........... <omitted>



void main() {
4004e0: 55 push %rbp
4004e1: 48 89 e5 mov %rsp,%rbp
4004e4: 48 83 ec 10 sub $0x10,%rsp
int g = testCall();
4004e8: b8 00 00 00 00 mov $0x0,%eax
4004ed: e8 da ff ff ff callq 4004cc &lt;testCall&gt;

........... <omitted>

For example, when we are inside testCall (i.e. from 4004cc onward), at every instruction, the .debug_frame information should allow us to restore all registers (such as rbp, rsp, eax etc.) to their previous status in the caller’s frame (here the caller is main).  This is done by keeping a table structure that keeps track of all the changes that happens with each register for every line of assembly. Referring to DWARF-2 Standard 6.4.1, the table structure is as follows:

LOC   CFA     R0 – RN

Where:

  • LOC is the assembly address (for example 4004cc), possible values are the address of each instruction
  • CFA is the current frame address (expressed by a register that serves as the SP/BP with an offset), more on this in the example below
  • R0-RN are the registers that the particular architecture has, possible values are:
    • Undefined, exactly what it says, the value of the register is whatever
    • Same, the value of the register is the same as the previous row on the table
    • Offset (N), the value of the register is now stored (as of this row’s LOC) at an offset N from CFA
    • Register (R), the value of the register is now stored in a new register R
In essence, the .debug_frame section and its corresponding cryptic tags are used to help the user construct such table.

Example Analysis

From this point onward, we are ready to introduce the example in Appendix of the standard, and analyze it. We start by looking at the first portion of the example to make sure it make sense.

Worth noting is that in this example given by the standard, fsize = 12 (as we can clearly see that the stack goes up by 12 at the most)


;; start prologue

foo     sub R7, R7,  fsize ; Allocate frame
foo+4   store R1, R7, (fsize-4) ; Save the return address
foo+8   store R6, R7, (fsize-8) ; Save R6
foo+12  add R6, R7, 0 ; R6 is now the Frame ptr
foo+16  store R4, R6, (fsize-12) ; Save a preserve reg.
;; This subroutine does not change R5
...
;; Start epilogue (R7 has been returned to entry value)
foo+64  load R4, R6, (fsize-12) ; Restore R4
foo+68  load R6, R7, (fsize-8) ; Restore R6
foo+72  load R1, R7, (fsize-4) ; Restore return address
foo+76  add R7, R7, fsize ; Deallocate frame
foo+80  jump R ; Return
foo+84

With table:

We will see that this makes sense:

  1. At LOC foo, nothing has happened yet (no instruction is run yet as the Program Counter is pointing to foo). The only thing that has been done, is that R8 (the PC) has been saved to R1 by the caller
  2. At foo+4, the instruction at location foo is run, making the current SP (R7) at R7-fsize. This means that the new CFA is now set to R7-fsize (See standard, CFA is the current frame address)
  3. At foo+8, the value of R1 is stored at R7-(fsize-4).
    1. Imagine with fsize = 12 and each data using 4 space, the current frame essentially has 3 slots. The top most one being fsize-4, middle is fsize-8, bottom most being fsize-12
    2. This means that the value of R1 (thus by proxy R8) is now stored on the stack at an offset of -4 from the current CFA (which is R7-fsize)
  4. At foo+16, see foo+12 moved the value R6 into R7 and so all CFA are now based on R6

The rest of the table pretty much follows the same thing so its easy to see.

 

Representation of the Table

So now we know how to track the table, we can see how to construct this table in the first place from .debug_frame. The reason why the table is not printed as it is is because this would be HUGE.

CIE:

This list shows how to construct the table structure. Read this in order:

  1. The CIE structure is 32 in length
  2. This CIE has no augmentation (cie+9 = 0)
  3. Code alignment factor is 4, so all location advancement needs /4
  4. Data alignment factor is 4, so all offset advancement needs *4
  5. The next one (cie+12) is the Register that holds the return address initially
  6. The rest of the cie structure can either be all nop to pad to the correct length, or they can be definitions to set up the first row of the table. See that the above example sets up the 1st row correctly

Once the table structure is set up, FDE describe how each new row is constructed. There is an FDE per function per compilation unit. (Usually only 1 CIE for each CU)

  1. Columns of new rows are initialized to the previous row first whenever a new row is added
  2. FDE+16, advance_loc(1) means insert a new row in the table
  3. FDE+17, def_cfa_offset means that the CFA column now has an offset at fsize/4 (4 being the data_alignment)
  4. FDE+18, add new row
  5. FDE+19, CFA_offset(8, 1), this means that register 8 is now stored at offset of 1*4 from CFA
  6. FDE+38, register 8 is restored to the initial value (first row of the table)

That’s it! This basically covers .debug_frame.

 

Posted in Debugger. Tagged with , , .

Port forwarding on VMWare Player 4.0.4

So VMWare Player supports NAT, but it does not offer a way to port forward anything so if you are running a server in the VM, chances are you can’t access it outside of the host.

But the installer has vmnetcfg.exe which allows configuration of NAT services, including port forwarding. To do this, look through the following steps:

  • Extract the utility by executing (in cmd) [VMWare Installer] /e tools
  • This creates a tools directory with all the installer content
  • Locate network.cab, open and extract vmnetcfg.exe to where VMWare Player is installed
  • Launch vmnetcfg and configure the NAT interface (https://www.vmware.com/support/ws5/doc/ws_net_nat_advanced.html)

Posted in Technology. Tagged with , , .

How to list directories with ls?

It just occurred to me that I didn’t know how to list only directories, so here it is:

ls -d */

How does this work?

  1. li -d lists only the directory entires, so instead of listing directory and also whats in it, it lists only the directory name
  2. */ is expended by the shell (bash in my case) into pwd/*/ (and this is why ls by itself just works, because pwd is appended automatically)
  3. So basically pwd/*/ means match everything with / at the end, which are directories, and -d says do not list whats inside. So all that are left are the directory names

Posted in Linux. Tagged with , .

grepping for

There are times when you want to have nos in source codes. So how do you grep for them?

grep -R '[CTRL+V][TAB]' .

Where [KEY] are actual key presses

Finding tabs within Vim is easy: /\t

Posted in C/C++, Java, Linux. Tagged with , .