'Domain'에 해당되는 글 103건

  1. 2006.08.30 [Spec] DWARF2
  2. 2006.05.13 [ARM] Exception generating codes...
  3. 2006.04.12 [VC][Tips] 2005 express

[Spec] DWARF2

Domain/Software 2006.08.30 00:42
[[ blog 이사 과정에서 정확한 posting날짜가 분실됨. 년도와 분기 정도는 맞지 않을까? ]]

[From DWARF Specification Version 2.0]

* Ambiguity in the Spec.
At first, let's see followings.

[Extracted from spec. page 66]
DW_CFA_def_cfa_offset takes a single unsigned LEB128 argument representing an offset -- (*1). The required action is to define the current CFA rule to use the provided offset (but to keep the old register).

[Extracted from spec. page 105]
fde + 17 DW_CFA_def_cfa_offset (<fsize>/4) -- (*2) ; assuming <fsize> < 512

As you can see above, in (*1) argument is just an offset. But in (*2), <fsize> is divided by '4'. So, I think there is conflict in those part.

In 'libdwarf', as (*1), it uses offset value itself. But, dwarf information generated by ADS1.2 compiler is obeys rule (*2) - offset * 4 (data alignment factor).

* How can we get Die from PC without 'Arrange Section'.

In this case, we can get CU Die from CU Header. And then, the result of sorting them into 'lowpc' order, can be used.

* Optimizing out local stack variable.

Unlike static or global variable, dwarf defines valid range for the local stack variable. That is, stack variable is valid only in this range. This may make mismatch between code and dwarf information; Sometimes, we seem to know value of variable when we look at the code, but in actual dwarf information, the variable is not valid yet, or optimized out. So, we cannot know it. Yes, this is totally compiler dependent.

Here is example.

    int a = 8;
    a = 10;   // --- (*)

"int a=8" is stored at NVRAM. So, compiler don't need to keep this value in memory. Therefore, before "a=10;", this value may not be assigned into the stack - that is, there is not relative dwarf information. As a result, we cannot read value "a" by reading register of memory. (In practice, this kind of stuffs often happens in ADS1.2 compiler.)

* Handling included source.
See follows.


    #include "a.c"

(ASSUMPTION : 'a.c' is not compiled separately)

In ADS1.2, 10th line of 'a.c' is regarded as 10th line of 'b.c'. So, there are two 10th lines in the dwarf information. I think some compiler may handle this case correctly. But, in ADS1.2, dwarf information is generated unexpectedly.

tags : dwarf
Trackback 0 : Comment 0

[ARM] Exception generating codes...

Domain/ARM 2006.05.13 14:00

[[ blog 이사 과정에서 정확한 posting날짜가 분실됨. 년도와 분기 정도는 맞지 않을까? ]]

Here are unexpected exceptions that can be occurred in SW(ARM).

  * Data Abort
  * Prefetch
  * Undefined Instruction
  * Divide by zero.

And here is sample code to raise these exceptions.

#pragma O0   /* disable all optimization */

typedef void (*_FuncT)(void);
void _test_data_abort(void)
    int   c;
    int*  p = (int*)0xdeaddead;
    c = *p;

void _test_prefetch_abort(void)
    _FuncT  f;
    f = (_FuncT)0xdeaddead;

static const int _undef_inst = 0xff0000ff;
void _test_undefined_instruction()
    _FuncT f;
    f = (_FuncT)(&_undef_inst);

(divide by zero) is omitted

In '_test_undefined_instruction()' , variable '_undef_inst' is located at 4byte-aligned-position. So, program mode becomes ARM mode when "f=(_FuncT)(&_undef_inst);" is executed - BX to 4byte-aligned-address (address & 0x1 == 0x00).

"MSB <--FFxxxxxx--> LSB" area is 'undefined instruction' area in ARM instruction. So, we can make endian-independent-'undefined instruction' by setting '_undef_inst' as 0xff0000ff.

'Domain > ARM' 카테고리의 다른 글

[ARM] Sample code for unwinding stack with DWARF2 information.  (0) 2010.04.07
[ARM] Sample code for unwinding stack in Thumb mode.  (0) 2010.04.07
[ARM] Unwinding Stack.  (0) 2009.09.15
[ARM] Long jump.  (0) 2007.06.05
[ARM] .init_array section  (0) 2007.03.18
[ARM] Exception generating codes...  (0) 2006.05.13
tags : Arm
Trackback 0 : Comment 0

[VC][Tips] 2005 express

Domain/Win32 2006.04.12 14:49

[[ blog 이사 과정에서 정확한 posting날짜가 분실됨. 년도와 분기 정도는 맞지 않을까? ]]

▶ Performance gab between using 'enum' and "using '#define' in Visual C++ 7.0
Environment : CPU: Intel 2.8G

Using enum:
    Number of enum items := 100,000 -> compiling takes very long time.
    Number of enum items := 10,000 -> very quick.
Using define
    Very quick even if number of defined items reaches 100,000.

Experimentally, if number of enum items are larger than specific threshold, compiling performance of VC++ 7.0 drops dramatically. So in this case, we would better to change 'enum' into '#define'.

▶ Order of finding 'include directory' in VC++ 7.0
"highest priority is directory where currently issued file is in.".
For example, lets consider following directory structure.

directory : xxx/src
=> a.c, c.h
directory : xxx/inc
=> b.h, c.h

(Let's assume that "xxx/inc" is added at "additional include directory").
"xxx/inc/b.h" and "xxx/inc/c.h" is used to compile "a.c". Even though compiler try to compile "a.c", "b.h" is issued file during parsing "b.h". And, "b.h" includes "c.h". So "c.h" in the directory where "b.h" is in, is included, because currently issued file is "b.h".

▶ Case that '.c' file and '.cpp' file whose basename are same, are in one VC Project in Visual 2005 Express C++.
For example, if there are 'a.c' and 'a.cpp' in one project, MSVC recognizes only '.cpp' file (based on experimental result). (I think the reason is that default compiler of VC is 'cpp' compiler.)
So, even if we modify 'a.c' and build, nothing is compiled because MSVC keep it's eyes on 'a.cpp' - it is not changed. (--> It's MSVC's bug!!)

▶ There is no way to compile one file with several different options in VC project. So we should use 'command line' to do this.

'Domain > Win32' 카테고리의 다른 글

[Win32][Tips] Creating Window...  (0) 2007.06.27
[Win32] IME Active중 VK Code얻기  (0) 2007.06.25
[Win32] 한글 입력하기  (0) 2007.06.23
[Tips] Cross-Compiling on Windows for Linux  (0) 2007.06.20
[Tips] cygwin 'make' issue  (0) 2007.06.13
[VC][Tips] 2005 express  (0) 2006.04.12
tags : Enum, Performance, VC
Trackback 0 : Comment 0