How to import identifier from startup.s (to main.c) - arm

I would like to locate a table of constant values with application data (equipment information), preferably at the end of the vector table.
In startup.s I do the following:
MODULE ?cstartup
;; Forward declaration of sections.
SECTION CSTACK:DATA:NOROOT(3)
SECTION .intvec:CODE:NOROOT(2)
EXTERN __iar_program_start
EXTERN SystemInit
PUBLIC __vector_table
PUBLIC _InfoEqData
DATA
__vector_table
DCD sfe(CSTACK)
DCD Reset_Handler ; Reset Handler
/* ............... */
DCD LCD_IRQHandler ; LCD
DCD USB_IRQHandler ; USB
__vector_table_end
_InfoEqData EQU __vector_table_end
In main.c I do the following:
#pragma location = _InfoEqData
const EqIdentify_t eqIdentify = { ... }
When I compile the code shows the following (expected) error
Error[Pe020]: identifier "_InfoEqData" is undefined ... \tst_vBus_main.cpp 25
How do I tell the compiler to find that identifier from startup.s?
Thanks in advance

The IAR toolchain supports #pragma location1 only to fix data at absolute addresses given by literal numbers2 or segment names3.
From my point of view, you should define an own segment in the linker command file3 and locate it according to your requirements.
1
IAR C/C++ Compiler User Guide for the 8051Microcontroller Architecture (C8051-7), Seventh edition: March 2017, page 372.
2
ibid., Seventh edition: March 2017, page 260.
3
ibid., Seventh edition: March 2017, page 262.
4
IAR Linker and Library Tools Reference Guide (XLINK-5001), April 2010, page 21.

Related

How to call DLL exported functions with #<number> at end of function name from C

I am trying to call functions from ntvdm.lib in Visual Studio 2019 using the Visual Studio 2017 - Windows XP (v141_XP) platform toolset, with the following defined:
#define _WIN32_WINNT 0x0501
#define i386
running dumpbin /exports on the LIB file I get the following output:
Microsoft (R) COFF/PE Dumper Version 14.29.30037.0
Copyright (C) Microsoft Corporation. All rights reserved.
Dump of file ntvdm.lib
File Type: LIBRARY
Exports
ordinal name
_BlockWOWIdle#4
_CurrentMonitorTeb
_DBGNotifyDebugged#4
_DBGNotifyNewTask#8
_DBGNotifyRemoteThreadAddress#8
_DispatchInterrupts#0
_Dos_Flag_Addr
_DpmiSetIncrementalAlloc#4
_ExpLdt
_FlatAddress
_GetDOSAppName#4
_InitialVdmDbgFlags
_InitialVdmTibFlags
_IsCdRomFile#4
_MGetVdmPointer#12
_RedirectLongFileName#12
_RedirectShortFileName#12
_RegisterWOWIdle#0
_ResumeTimerThread#0
_SelectorLimit
_SetShadowDescriptorEntries#8
_ShortPathEnvVar#4
_Sim32pGetVDMPointer#8
_SoftPcEoi#8
_SuspendTimerThread#0
_VDDAllocMem#12
_VDDAllocateDosHandle#12
_VDDAssociateNtHandle#12
_VDDDeInstallIOHook#12
_VDDDeInstallMemoryHook#12
_VDDDeInstallUserHook#4
_VDDExcludeMem#12
_VDDFreeMem#12
_VDDIncludeMem#12
_VDDInstallIOHook#16
_VDDInstallMemoryHook#16
_VDDInstallUserHook#20
_VDDQueryDMA#12
_VDDReleaseDosHandle#8
_VDDReleaseIrqLine#8
_VDDRequestDMA#16
_VDDReserveIrqLine#8
_VDDRetrieveNtHandle#16
_VDDSetDMA#16
_VDDSimulate16#0
_VDDTerminateVDM#0
_VdmDbgAttach#0
_VdmGetParametersInfoError#0
_VdmMapFlat#12
_VdmParametersInfo#12
_VdmTraceEvent#12
_WOWSysErrorBox#20
_WaitIfIdle#0
_call_ica_hw_interrupt#12
_cmdCheckTemp#4
_cmdCheckTempInit#0
_cpu_createthread#8
_demClientErrorEx#12
_demFileDelete#4
_demFileFindFirst#12
_demFileFindNext#4
_demGetFileTimeByHandle_WOW#4
_demGetPhysicalDriveType#4
_demIsShortPathName#8
_demLFNCleanup#0
_demLFNGetCurrentDirectory#8
_demSetCurrentDirectoryGetDrive#8
_demWOWLFNAllocateSearchHandle#4
_demWOWLFNCloseSearchHandle#4
_demWOWLFNEntry#4
_demWOWLFNGetSearchHandle#4
_demWOWLFNInit#4
_fSeparateWow
_getAF#0
_getAH#0
_getAL#0
_getAX#0
_getBH#0
_getBL#0
_getBP#0
_getBX#0
_getCF#0
_getCH#0
_getCL#0
_getCS#0
_getCX#0
_getDF#0
_getDH#0
_getDI#0
_getDL#0
_getDS#0
_getDX#0
_getEAX#0
_getEBP#0
_getEBX#0
_getECX#0
_getEDI#0
_getEDX#0
_getEFLAGS#0
_getEIP#0
_getES#0
_getESI#0
_getESP#0
_getFS#0
_getGS#0
_getIF#0
_getIP#0
_getIntelRegistersPointer#0
_getMSW#0
_getOF#0
_getPF#0
_getSF#0
_getSI#0
_getSP#0
_getSS#0
_getZF#0
_host_CreateThread#24
_host_ExitThread#4
_host_com_close#4
_host_direct_access_error#4
_host_simulate#0
_pDeviceChain
_setAF#4
_setAH#4
_setAL#4
_setAX#4
_setBH#4
_setBL#4
_setBP#4
_setBX#4
_setCF#4
_setCH#4
_setCL#4
_setCS#4
_setCX#4
_setDF#4
_setDH#4
_setDI#4
_setDL#4
_setDS#4
_setDX#4
_setEAX#4
_setEBP#4
_setEBX#4
_setECX#4
_setEDI#4
_setEDX#4
_setEFLAGS#4
_setEIP#4
_setES#4
_setESI#4
_setESP#4
_setFS#4
_setGS#4
_setIF#4
_setIP#4
_setMSW#4
_setOF#4
_setPF#4
_setSF#4
_setSI#4
_setSP#4
_setSS#4
_setZF#4
Summary
BD .debug$S
14 .idata$2
14 .idata$3
4 .idata$4
4 .idata$5
A .idata$6
The function definition I'm trying to call in VDDSVC.h is:
#define GetVDMPointer(Address, Size, Mode) Sim32GetVDMPointer(\
Address, Size, Mode)
However visual studio error is:
Error LNK2019 unresolved external symbol _MGetVdmPointer referenced in function _VddDispatch
_MGetVdmPointer is in the lib file but referenced as _MGetVdmPointer#12
I reviewed the options here but couldn't determine which one might apply in my scenario https://learn.microsoft.com/en-us/cpp/error-messages/tool-errors/linker-tools-error-lnk2019?view=msvc-170
In Linker -> General -> Show Progress I tried setting /VERBOSE although no additional information was generated in the logs
I tried changing calling convention to "__stdcall" in C/C++ -> Advanced Calling Convention
I've tried changing files from .C to .CPP although get similar error (Although the symbol looked for is a c++ mangled style name)
The issue was calling convention needs to be modified to "__stdcall" in C/C++ -> Advanced Calling Convention
Which I had tried, however Visual Studio 2019 project properties was defaulting to configuration for "Release" build and not the current build type "Debug(Active)" which effectively made my initial change of that setting ineffective.
As suggested in comments by IInspectable:
When changing global project properties, always make sure the "Configuration" is set to "All Configurations" and "Platform" is set to "All Platforms"

"no such instruction error" when assembling an array declaration:

I have the following piece of x86 assembly code:
1
2 .text
3
4 .data
5
6 # define an array of 3 dwords
7 array_word DW 1, 2, 3
8
9
10 .globl main
11
12main:
13 # nothing interesting ..
14
But when I compile this, I keep getting the following error:
$ gcc my_asm.s
my_asm.s: Assembler messages:
my_asm.s:7: Error: no such instruction: `array_word DW 1,2,3'
This is the gcc I use:
$ gcc --version
gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-16)
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Your syntax is wrong - gas (which is invoked by gcc for assembly files) uses a different syntax than other assemblers like NASM.
Use
array_word: .word 1, 2, 3
See also https://sourceware.org/binutils/docs/as/Word.html#Word
Note that the result of .word is target CPU specific - an alternative is .hword:
7.60 .hword expressions
This expects zero or more expressions, and emits a 16 bit number for
each.
This directive is a synonym for .short; depending on the target architecture, it may also be a synonym for .word.
By the way: you say # define an array of 3 dwords in your comment - but note that DW is Define Word which defines a 16 bit word. In NASM, you would use DD for 32 bit words.

error: L6236E: No section matches selector - no section to be FIRST/LAST

I'm new to ARM programming using Keil Microvision V5.12 compiler.
I can't compile a simple assembly project getting this error:
.\Objects\learn.sct(7): error: L6236E: No section matches selector - no section to be FIRST/LAST.
I've tried searching and couldn't find any solution for this problem.
This is what I do:
Create a project (without the startup file)
Add a new assembly file (learn.s)
Click Build Target.
Can anybody help?
I Added this answer for newbies,
So, After create new project do same as picture:
There is no 'FIRST' object in your source code. Your scatter file likely looks something like:
LR_IROM1 0x08000000 0x00040000 { ; load region size_region
ER_IROM1 0x08000000 0x00040000 { ; load address = execution address
*.o (RESET, +First)
*(InRoot$$Sections)
.ANY (+RO)
}
RW_IRAM1 0x20000000 0x0000A000 { ; RW data
.ANY (+RW +ZI)
}
}
The _FIRST object that the linker wants to put into the image is the area called RESET. You do not have a RESET region in your code.
Add something along the lines of
AREA RESET, DATA, READONLY
to your assembly file where you want execution to begin.
Create a project with the startup file and look for the AREA RESET ..... declaration and copy that.
For Cortex it looks like:
AREA RESET, DATA, READONLY
EXPORT __Vectors
EXPORT __Vectors_End
EXPORT __Vectors_Size
__Vectors DCD __initial_sp ; Top of Stack
DCD Reset_Handler ; Reset Handler
DCD NMI_Handler ; NMI Handler
DCD HardFault_Handler ; Hard Fault Handler
DCD MemManage_Handler ; MPU Fault Handler
DCD BusFault_Handler ; Bus Fault Handler
DCD UsageFault_Handler ; Usage Fault Handler
DCD 0
Each of those handlers needs to be declared, but you can just add the stack pointer and reset handler to get started.
For ARM LPC the startup assembly file Startup.s is something like this:
AREA MyStacks, DATA, NOINIT, ALIGN=2
IrqStackSpace SPACE IRQ_STACK_LEGTH * 4
FiqStackSpace SPACE FIQ_STACK_LEGTH * 4
AbtStackSpace SPACE ABT_STACK_LEGTH * 4
UndtStackSpace SPACE UND_STACK_LEGTH * 4
AREA RESET, DATA, READONLY
bottom_of_heap SPACE 1
AREA RESET, DATA, READONLY
StackUsr SPACE 1
Just replacing does the trick.
This error will occur If you select HSI in Clock configuration at cubeMX although you've already selected HSE in RCC. If you choose one of them (HSI/HSE) it will be solved
I face same problem. Source (.c) fil and (.uvproj) file should same location and you can not copy from others location.So create

Lua unable to load VC++ dll

I have compiled my litertools project as a .dll using the Visual Studio C/C++ toolchain and it correctly exports the lua_openlitertools function:
PS> dumpbin /exports .\bin\lib\litertools.dll
Microsoft (R) COFF/PE Dumper Version 14.00.22013.1
Dump of file .\bin\lib\litertools.dll
Section contains the following exports for litertools.dll
00000000 characteristics
5439D35E time date stamp Sun Oct 12 12:03:26 2014
0.00 version
1 ordinal base
1 number of functions
1 number of names
ordinal hint RVA name
1 0 000227AD luaopen_litertools = #ILT+1960(_luaopen_litertools)
Summary
1000 .data
2000 .idata
6000 .rdata
2000 .reloc
1000 .rsrc
44000 .text
21000 .textbss
When I set configure package.cpath and then require the litertools dll by doing:
CMD> lua -e "package.cpath=\".\\bin\\lib\\?.dll\"; require(\"litertools\")"
I receive the following error
lua: error loading module 'litertools' from file '.\bin\lib\litertools.dll':
The specified module could not be found.
stack traceback:
[C]: in ?
[C]: in function 'require'
(command line):1: in main chunk
[C]: in ?
Looking into it, I debugged the call through require (loadlib.c), and got to here:
static void *ll_load (lua_State *L, const char *path, int seeglb) {
HMODULE lib = LoadLibraryExA(path, NULL, LUA_LLE_FLAGS);
(void)(seeglb); /* not used: symbols are 'global' by default */
if (lib == NULL) pusherror(L);
return lib;
}
The call to LoadLibraryExA returns NULL. I am unsure as to why this happens, though I have compiled the same library using mingw-gcc and was able to require the dll.
I figured out that dependency was not being found through using:
http://www.dependencywalker.com/
Move the unit tests into a separate project and corrected solution settings.

C Program Written in VS2012 Works w/ Win7/8/2008R2/2012, but not 2003/XP/32bit?

I have to start by saying that I am very much a programming noob. I do not understand all the compiler options or nuances of the IDE, not by a longshot. But I am trying to teach myself more about native programming languages. (I'm decent with C#, but that is much easier than C as I am discovering.)
Today, I wrote this small program in C. It is a console/command line program. I used Visual Studio 2012 and my development machine alternates between Windows 7 and 8, 64 bit. To start, what I did was create a new VC++ project, and I chose a Blank Project. Then I created a new app.c file. I also created a *.rc file to give the executable some extra properties like "File Version" and "Company Name" when you browse the file properties in Windows Explorer. Then I went to the properties of the project, chose Configuration Properties -> C/C++ -> Code Generation and I changed Runtime Library to "Multi-threaded (/MT) so that I wouldn't have to distribute the msvcr100.dll file along with my executable.
In the app.c file, I placed the following code:
#include <stdio.h>
#include <string.h>
#include <Windows.h>
#include <WtsApi32.h>
#pragma comment(lib, "WtsApi32.lib")
void main(int argc, char *argv[])
{
char *helpMsg = "blah";
char *hostName, *connState = "";
char *addrFamily = "";
HANDLE hHost = NULL;
...stuff and so forth and so on...
}
Then I built/compiled the program, and the executable works just fine on Windows 7, 8, Server 2008R2, Server 2012, all 64 bit. But when I try to run the program on Server 2003 (and I am guessing WinXP, etc., as well,) I am greeted with the Windows dialog box:
"Foo.exe is not a valid Win32 application."
So my question is, is there something obvious/simple that I am missing that will allow this executable to also work on earlier XP/2003/32bit platforms that I am missing? I do not believe that I am using any 64-bit exclusive features in my program. But I figured that since I did choose "Blank Project" instead of "Win32 Console Application" that I may be missing some setting.
Edit: Here is the dumpbin.exe /headers output when run against my exe:
Microsoft (R) COFF/PE Dumper Version 11.00.50727.1
Copyright (C) Microsoft Corporation. All rights reserved.
Dump of file C:\users\me\Release\foo.exe
PE signature found
File Type: EXECUTABLE IMAGE
FILE HEADER VALUES
14C machine (x86)
5 number of sections
50F604BC time date stamp Tue Jan 15 19:39:08 2013
0 file pointer to symbol table
0 number of symbols
E0 size of optional header
102 characteristics
Executable
32 bit word machine
OPTIONAL HEADER VALUES
10B magic # (PE32)
11.00 linker version
7800 size of code
A200 size of initialized data
0 size of uninitialized data
16A7 entry point (004016A7) _mainCRTStartup
1000 base of code
9000 base of data
400000 image base (00400000 to 00414FFF)
1000 section alignment
200 file alignment
6.00 operating system version
0.00 image version
6.00 subsystem version
0 Win32 version
15000 size of image
400 size of headers
0 checksum
3 subsystem (Windows CUI)
8140 DLL characteristics
Dynamic base
NX compatible
Terminal Server Aware
100000 size of stack reserve
1000 size of stack commit
100000 size of heap reserve
1000 size of heap commit
0 loader flags
10 number of directories
0 [ 0] RVA [size] of Export Directory
D374 [ 3C] RVA [size] of Import Directory
11000 [ 538] RVA [size] of Resource Directory
0 [ 0] RVA [size] of Exception Directory
0 [ 0] RVA [size] of Certificates Directory
12000 [ C04] RVA [size] of Base Relocation Directory
9160 [ 38] RVA [size] of Debug Directory
0 [ 0] RVA [size] of Architecture Directory
0 [ 0] RVA [size] of Global Pointer Directory
0 [ 0] RVA [size] of Thread Storage Directory
CF98 [ 40] RVA [size] of Load Configuration Directory
0 [ 0] RVA [size] of Bound Import Directory
9000 [ 118] RVA [size] of Import Address Table Directory
0 [ 0] RVA [size] of Delay Import Directory
0 [ 0] RVA [size] of COM Descriptor Directory
0 [ 0] RVA [size] of Reserved Directory
SECTION HEADER #1
.text name
7670 virtual size
1000 virtual address (00401000 to 0040866F)
7800 size of raw data
400 file pointer to raw data (00000400 to 00007BFF)
0 file pointer to relocation table
0 file pointer to line numbers
0 number of relocations
0 number of line numbers
60000020 flags
Code
Execute Read
SECTION HEADER #2
.rdata name
49E2 virtual size
9000 virtual address (00409000 to 0040D9E1)
4A00 size of raw data
7C00 file pointer to raw data (00007C00 to 0000C5FF)
0 file pointer to relocation table
0 file pointer to line numbers
0 number of relocations
0 number of line numbers
40000040 flags
Initialized Data
Read Only
Debug Directories
Time Type Size RVA Pointer
-------- ------ -------- -------- --------
50F604BC cv 61 0000CFE0 BBE0 Format: RSDS, {582D0FF2-59C1-4633-AF2A-E4A4AD6BFA2C}, 1, C:\Users\me\Release\users.pdb
50F604BC feat 10 0000D044 BC44 Counts: Pre-VC++ 11.00=0, C/C++=116, /GS=116, /sdl=0
SECTION HEADER #3
.data name
2C04 virtual size
E000 virtual address (0040E000 to 00410C03)
E00 size of raw data
C600 file pointer to raw data (0000C600 to 0000D3FF)
0 file pointer to relocation table
0 file pointer to line numbers
0 number of relocations
0 number of line numbers
C0000040 flags
Initialized Data
Read Write
SECTION HEADER #4
.rsrc name
538 virtual size
11000 virtual address (00411000 to 00411537)
600 size of raw data
D400 file pointer to raw data (0000D400 to 0000D9FF)
0 file pointer to relocation table
0 file pointer to line numbers
0 number of relocations
0 number of line numbers
40000040 flags
Initialized Data
Read Only
SECTION HEADER #5
.reloc name
235C virtual size
12000 virtual address (00412000 to 0041435B)
2400 size of raw data
DA00 file pointer to raw data (0000DA00 to 0000FDFF)
0 file pointer to relocation table
0 file pointer to line numbers
0 number of relocations
0 number of line numbers
42000040 flags
Initialized Data
Discardable
Read Only
Summary
3000 .data
5000 .rdata
3000 .reloc
1000 .rsrc
8000 .text
I have also tried going to Project Properties -> Linker -> System: Minimum Required Version and changing that to 5.00 and 1.00 or whatever, but it has no effect. dumpbin.exe still reports the OS version as 6.00. I have even used editbin.exe /version 5.00 on the exe and no errors were reported... and yet dumpbin.exe still reports 6.00 for the OS version.
VS2012 originally shipped without supporting XP/2003. The updated CRT and runtime support libraries are using too many Windows api functions that are not available on those operating systems. This created quite a stir among its customers, to put it mildly, and they re-engineered the libraries to dynamically bind to these functions and limp along it they are missing. This was made available in Update 1, you'll need to use Project + Properties, General, Platform Toolset = v110_xp to build programs that use those libraries.
Note how it changes a linker setting, the important one, Linker > System > Minimum Required Version = "5.01". Which ensures that the executable file is marked to be compatible with the XP sub-system version. You'll also build against SDK version 7.1, the last one that is still compatible with XP.
When you use the default toolset (v110) then you target sub-system 6.00 and SDK version 8. Version 6.00 was the last major kernel revision, started with Vista.
A brief overview of the new api functions being used to give you a (very rough) idea what is missing in the XP version:
FlsAlloc, FlsFree, FlsGetValue, FlsSetValue : safe thread-local storage
InitializeCriticalSectionEx, CreateSemaphoreEx : safety
SetThreadStackGuarantee : stability
CreateThreadPoolTimer, SetThreadPoolTimer, WaitForThreadPoolTimerCallbacks, CloseThreadPoolTimer : cheaper timers
CreateThreadPoolWait, SetThreadPoolWait, CloseThreadPoolWait : cheaper waits?
FlushProcessWriteBuffers, GetCurrentProcessorNumber, GetLogicalProcessorInformation : threading
FreeLibraryWhenCallbackReturns : stability?
CreateSymbolicLink : functionality
InitOnceExecuteOnce : unknown
SetDefaultDllDirectories : unknown
EnumLocalesEx, CompareStringEx, GetDateFormatEx, GetLocalInfoEx, GetTimeFormatEx, GetUserDefaultLocaleName, IsValidLocaleName, LCMapStringEx : better locale support
I figured it out myself. (But thank you Hans for steering me in the right direction.) For some reason, even with Update 1 and even after setting my toolset to v110_xp, and setting the minimum required version to 5.01 in the Linker options, the resulting dumpbin app.exe /headers still reports a minimum operating system version of 6.0.
So I simply ran
editbin.exe app.exe /SUBSYSTEM:CONSOLE,5.01 /OSVERSION:5.1
And the executable now runs just fine on older operating systems. I'm thinking there still might be a little bit of a bug somewhere in Visual Studio.
The MSVC Team Blog says that when using MSBuild or DEVENV from the command-line with the v110_xp platform toolset, no other changes are necessary. This information is incorrect/incomplete. The /SUBSYSTEM linker argument and associated "Minimum Required Version" must also be set appropriately.
The MSDN documentation for /ENTRY states that, if the /SUBSYSTEM argument is not specified that the SUBSYSTEM and ENTRY POINT are determined automatically. My hunch is that when this happens, the SUBSYSTEM's "Minimum Required Version" argument is also automatically overridden.
The v110_xp toolset automatically specifies the SUBSYSTEM's MRV ("5.1" (WindowsXP)) but not the SUBSYSTEM. As such, the MRV will be overridden, for example, by the linker to "6.0". Running the application will then cause WindowsXP to show the error message stating that the application "is not a valid Win32 application."

Resources