If two kernel module contain EXPORT_SYMBOL(a), a is defined as: int a, what will happen if two module was inserted? which "a" will be used?
You can't insert duplicate symbols into the kernel. Example:
The xor module loaded in my kernel
nwatkins#kyoto:~$ lsmod | grep xor
xor 4685 1 async_xor
The exported xor_blocks symbol in the xor module
nwatkins#kyoto:~$ nm /lib/modules/2.6.32-24-generic/kernel/crypto/xor.ko | grep xor_blocks
0000000000000000 r __kcrctab_xor_blocks
0000000000000000 r __kstrtab_xor_blocks
0000000000000000 r __ksymtab_xor_blocks
0000000000000bb0 T xor_blocks
Another exported xor_blocks symbol in a module I created
nwatkins#kyoto:~$ nm mod-t1.ko | grep xor
0000000000000000 r __kcrctab_xor_blocks
0000000000000000 r __kstrtab_xor_blocks
0000000000000000 r __ksymtab_xor_blocks
0000000000000000 T xor_blocks
Error reported from insmod
nwatkins#kyoto:~$ sudo insmod mod-t1.ko
insmod: error inserting 'mod-t1.ko': -1 Invalid module format
Duplicate error message from dmesg
[422002.174033] mod_t1: exports duplicate symbol xor_blocks (owned by xor)
Related
My Go application connect to IBM MQ.
When my application throws segmentation violation error (signal SIGSEGV), signal handlers registered by IBM MQ make my application throw "non-Go code set up signal handler without SA_ONSTACK flag".
So how can I set that flag?
My code
package main
import (
"fmt"
"github.com/ibm-messaging/mq-golang/ibmmq"
)
type A struct {
Str string
}
type B struct {
Apointer *A
}
func main() {
connectIBMMQ()
b := B{}
fmt.Println(b.Apointer.Str)
}
const (
QMgrName = `QMgrName`
ChannelName = `ChannelName`
ConnectionName = `0.0.0.0(1416)`
Username = `username`
Password = `password`
)
func connectIBMMQ() {
mqcd := ibmmq.NewMQCD()
mqcd.ChannelName = ChannelName
mqcd.ConnectionName = ConnectionName
csp := ibmmq.NewMQCSP()
csp.AuthenticationType = ibmmq.MQCSP_AUTH_USER_ID_AND_PWD
csp.UserId = Username
csp.Password = Password
cno := ibmmq.NewMQCNO()
cno.ClientConn = mqcd
cno.Options = ibmmq.MQCNO_CLIENT_BINDING + ibmmq.MQCNO_RECONNECT + ibmmq.MQCNO_HANDLE_SHARE_BLOCK
cno.SecurityParms = csp
ibmmq.Connx(QMgrName, cno)
}
Ref
https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_9.1.0/com.ibm.mq.dev.doc/q025880_.htm
https://golang.org/pkg/os/signal/#hdr-Go_programs_that_use_cgo_or_SWIG
Full error
signal 11 received but handler not on signal stack
fatal error: non-Go code set up signal handler without SA_ONSTACK flag
runtime stack:
runtime: unexpected return pc for runtime.sigtramp called from 0x7f60f6e9a517
stack: frame={sp:0xc000046628, fp:0xc000046680} stack=[0xc00003e578,0xc000046978)
000000c000046528: 000000c000046530 00000000004549a0 <runtime.throw.func1+0>
000000c000046538: 00000000004e2c3b 0000000000000039
000000c000046548: 000000c000046568 00000000004415df <runtime.sigNotOnStack+127>
000000c000046558: 00000000004e2c3b 0000000000000039
000000c000046568: 000000c000046618 0000000000440c6d <runtime.sigtrampgo+749>
000000c000046578: 000000000000000b 000000c000046600
000000c000046588: 000000c000046880 0000000000000000
000000c000046598: 0000000000000000 000000c000046628
000000c0000465a8: 0000000000000000 0000000000000000
000000c0000465b8: 0000000000000000 0000000000000000
000000c0000465c8: 0000000000000000 000000c000000180
000000c0000465d8: 0000000000000000 ffffffffffffffff
000000c0000465e8: 0000000000000000 0000000000000000
000000c0000465f8: 0000000000000000 000000c000002000
000000c000046608: 0000000000000000 0000000000008000
000000c000046618: 000000c000046670 0000000000459a33 <runtime.sigtramp+67>
000000c000046628: <000000000000000b 000000c0000469b0
000000c000046638: 000000c000046880 000000c000046880
000000c000046648: 000000c0000469b0 0000000000000000
000000c000046658: 000000000000000b 000000c000046670
000000c000046668: 00007f60f78213c0 000000000262e400
000000c000046678: !00007f60f6e9a517 >000000c000046690
000000c000046688: 8e26f8f48c919100 0000000000000000
000000c000046698: 0000000000000000 0000000000000008
000000c0000466a8: 0000000000000000 000000c000000180
000000c0000466b8: 0000000000000000 0000000000000000
000000c0000466c8: 0000000000000000 0000000000000000
000000c0000466d8: 0000000000000000 0000000000000000
000000c0000466e8: 0000000000000000 0000000000000000
000000c0000466f8: 0000000000000000 0000000000000000
000000c000046708: 0000000000000000 0000000000000000
000000c000046718: 0000000000000000 000000c000046f88
000000c000046728: 0000000000000004 0000000000000012
000000c000046738: 00000000004f21e1 0000000000000000
000000c000046748: 00007f60f6e9b45a 0000000000000000
000000c000046758: 0000000000000000 0000000000000000
000000c000046768: 0000000000000000 0000000000000000
000000c000046778: 0000000000000000
runtime.throw(0x4e2c3b, 0x39)
/usr/local/go/src/runtime/panic.go:617 +0x72
runtime.sigNotOnStack(0xb)
/usr/local/go/src/runtime/signal_unix.go:576 +0x7f
runtime.sigtrampgo(0xb, 0xc0000469b0, 0xc000046880)
/usr/local/go/src/runtime/signal_unix.go:334 +0x2ed
runtime: unexpected return pc for runtime.sigtramp called from 0x7f60f6e9a517
stack: frame={sp:0xc000046628, fp:0xc000046680} stack=[0xc00003e578,0xc000046978)
000000c000046528: 000000c000046530 00000000004549a0 <runtime.throw.func1+0>
000000c000046538: 00000000004e2c3b 0000000000000039
000000c000046548: 000000c000046568 00000000004415df <runtime.sigNotOnStack+127>
000000c000046558: 00000000004e2c3b 0000000000000039
000000c000046568: 000000c000046618 0000000000440c6d <runtime.sigtrampgo+749>
000000c000046578: 000000000000000b 000000c000046600
000000c000046588: 000000c000046880 0000000000000000
000000c000046598: 0000000000000000 000000c000046628
000000c0000465a8: 0000000000000000 0000000000000000
000000c0000465b8: 0000000000000000 0000000000000000
000000c0000465c8: 0000000000000000 000000c000000180
000000c0000465d8: 0000000000000000 ffffffffffffffff
000000c0000465e8: 0000000000000000 0000000000000000
000000c0000465f8: 0000000000000000 000000c000002000
000000c000046608: 0000000000000000 0000000000008000
000000c000046618: 000000c000046670 0000000000459a33 <runtime.sigtramp+67>
000000c000046628: <000000000000000b 000000c0000469b0
000000c000046638: 000000c000046880 000000c000046880
000000c000046648: 000000c0000469b0 0000000000000000
000000c000046658: 000000000000000b 000000c000046670
000000c000046668: 00007f60f78213c0 000000000262e400
000000c000046678: !00007f60f6e9a517 >000000c000046690
000000c000046688: 8e26f8f48c919100 0000000000000000
000000c000046698: 0000000000000000 0000000000000008
000000c0000466a8: 0000000000000000 000000c000000180
000000c0000466b8: 0000000000000000 0000000000000000
000000c0000466c8: 0000000000000000 0000000000000000
000000c0000466d8: 0000000000000000 0000000000000000
000000c0000466e8: 0000000000000000 0000000000000000
000000c0000466f8: 0000000000000000 0000000000000000
000000c000046708: 0000000000000000 0000000000000000
000000c000046718: 0000000000000000 000000c000046f88
000000c000046728: 0000000000000004 0000000000000012
000000c000046738: 00000000004f21e1 0000000000000000
000000c000046748: 00007f60f6e9b45a 0000000000000000
000000c000046758: 0000000000000000 0000000000000000
000000c000046768: 0000000000000000 0000000000000000
000000c000046778: 0000000000000000
runtime.sigtramp(0xc000046690, 0x8e26f8f48c919100, 0x0, 0x0, 0x8, 0x0, 0xc000000180, 0x0, 0x0, 0x0, ...)
/usr/local/go/src/runtime/sys_linux_amd64.s:357 +0x43
goroutine 17 [syscall, locked to thread]:
runtime.goexit()
/usr/local/go/src/runtime/asm_amd64.s:1337 +0x1 fp=0xc00004afe8 sp=0xc00004afe0 pc=0x457e41
goroutine 1 [running]:
goroutine running on other thread; stack unavailable
You can try setting the environment variable "MQS_NO_SYNC_SIGNAL_HANDLING=true" to disable some of MQ's signal setting. That should at least give a better idea of where the SEGV is coming from.
I have a question about ELF dynamic symbol table. For symbols of type FUNC, I have noticed a value of 0 in some binaries. But in other binaries, it has some non-zero value. Both these binaries were generated by gcc, I want to know why is this difference?. Is there any compiler options to control this?
EDIT: This is the output of readelf --dyn-syms prog1
Symbol table '.dynsym' contains 5 entries:
Num: Value Size Type Bind Vis Ndx Name
0: 00000000 0 NOTYPE LOCAL DEFAULT UND
1: 00000000 0 NOTYPE WEAK DEFAULT UND __gmon_start__
2: 000082f0 0 FUNC GLOBAL DEFAULT UND printf#GLIBC_2.4 (2)
3: 00008314 0 FUNC GLOBAL DEFAULT UND abort#GLIBC_2.4 (2)
4: 000082fc 0 FUNC GLOBAL DEFAULT UND __libc_start_main#GLIBC_2.4
Here value of "printf" symbol is 82f0 which happens to be the address of plt table entry for printf.
Output of readelf --dyn-syms prog2
Symbol table '.dynsym' contains 6 entries:
Num: Value Size Type Bind Vis Ndx Name
0: 00000000 0 NOTYPE LOCAL DEFAULT UND
1: 00000000 0 NOTYPE WEAK DEFAULT UND __gmon_start__
2: 00000000 0 FUNC GLOBAL DEFAULT UND puts#GLIBC_2.4 (2)
3: 00000000 0 FUNC GLOBAL DEFAULT UND printf#GLIBC_2.4 (2)
4: 00000000 0 FUNC GLOBAL DEFAULT UND abort#GLIBC_2.4 (2)
5: 00000000 0 FUNC GLOBAL DEFAULT UND __libc_start_main#GLIBC_2.4
Here the values for all the symbols are zero.
The x86_64 SV ABI mandates that (emphasis mine):
To allow comparisons of function addresses to work as expected,
if an executable file references a function defined in a shared object,
the link editor will place the address of the procedure linkage table
entry for that function in its associated symbol table entry.
This will result in symbol table entries with section index of
SHN_UNDEF but a type of STT_FUNC and a non-zero st_value.
A reference to the address of a function from within a shared
library will be satisfied
by such a definition in the executable.
With my GCC, this program:
#include <stdio.h>
int main()
{
printf("hello %i\n", 42);
return 0;
}
when compiled directly into an executable generates a null value:
1: 0000000000000000 0 FUNC GLOBAL DEFAULT UND printf#GLIBC_2.2.5 (2)
But this program with a comparison of the printf function:
#include <stdio.h>
int main()
{
printf("hello %i\n", 42);
if (printf == puts)
return 1;
return 0;
}
generates a non-null value:
3: 0000000000400410 0 FUNC GLOBAL DEFAULT UND printf#GLIBC_2.2.5 (2)
In the .o file, the first program generates:
000000000014 000a00000002 R_X86_64_PC32 0000000000000000 printf - 4
and the second:
000000000014 000a00000002 R_X86_64_PC32 0000000000000000 printf - 4
000000000019 000a0000000a R_X86_64_32 0000000000000000 printf + 0
The difference is caused by the extra R_X86_64_32 relocation for getting the address of the function.
Observations by running readelf on some binary
All the FUNCTIONS which are UNDEFINED have size zero.
These undefined functions are those which are called through libraries. In my small ELF binary all references to GLIBc are undefined with size zero
From http://docs.oracle.com/cd/E19457-01/801-6737/801-6737.pdf on page 21
It becomes clear that symbol table can have three types of symbols. Among these three, two types UNDEFINED and TENTATIVE symbols are those which are with out storage assigned. in later case you can see in readelf output, some functions which are not undefined(have index) and does not have storage.
for clarity undefined symbols are those which are referenced but does not assign storage(have not been created yet) while tentative symbols are those which are created but w/o assigned storage. e.g uninitialized symbols
edit
if you are talking about .plt, shared libraries symbols bind is lazy.
how to control the bind see http://www.linuxjournal.com/article/1060
This feature is known as lazy symbol binding. The idea is that if you have lots of shared libraries, it could take the dynamic loader lots of time to look up all of the functions to initialize all of the .plt slots, so it would be preferable to defer binding addresses to the functions until we actually need them. This turns out to be a big win if you only end up using a small fraction of the functions in a shared library. It is possible to instruct the dynamic loader to bind addresses to all of the .plt slots before transferring control to the application—this is done by setting the environment variable LD_BIND_NOW=1 before running the program. This turns out to be useful in some cases when you are debugging a program, for example. Also, I should point out that the .plt is in read-only memory. Thus the addresses used for the target of the jump are actually stored in the .got section. The .got also contains a set of pointers for all of the global variables that are used within a program that come from a shared library.
I'm compiling a very simple hello-world one-liner statically on Debian 7 system on x86_64 machine with gcc version 4.8.2 (Debian 4.8.2-21):
gcc test.c -static -o test
and I get an executable ELF file that includes the following sections:
[17] .tdata PROGBITS 00000000006b4000 000b4000
0000000000000020 0000000000000000 WAT 0 0 8
[18] .tbss NOBITS 00000000006b4020 000b4020
0000000000000030 0000000000000000 WAT 0 0 8
[19] .init_array INIT_ARRAY 00000000006b4020 000b4020
0000000000000010 0000000000000000 WA 0 0 8
[20] .fini_array FINI_ARRAY 00000000006b4030 000b4030
0000000000000010 0000000000000000 WA 0 0 8
[21] .jcr PROGBITS 00000000006b4040 000b4040
0000000000000008 0000000000000000 WA 0 0 8
[22] .data.rel.ro PROGBITS 00000000006b4060 000b4060
00000000000000e4 0000000000000000 WA 0 0 32
Note that .tbss section is allocated at addresses 0x6b4020..0x6b4050 (0x30 bytes) and it intersects with allocation of .init_array section at 0x6b4020..0x6b4030 (0x10 bytes), .fini_array section at 0x6b4030..0x6b4040 (0x10 bytes) and with .jcr section at 0x6b4040..0x6b4048 (8 bytes).
Note it does not intersect with the following sections, for example, .data.rel.ro, but that's probably because .data.rel.ro alignment is 32 and thus it can't be placed any earlier than 0x6b4060.
The resulting file runs ok, but I still don't exactly get how it works. From what I read in glibc documentation, .tbss is a just .bss section for thread local storage (i.e. allocated memory scratch space, not really mapped in physical file). Is it that .tbss section is so special that it can overlap other sections? Are .init_array, .fini_array and .jcr are so useless (for example, they are not needed anymore then TLS-related code runs), so they can be overwritten by bss? Or is it some sort of a bug?
Basically, what do I get to read and write if I'll try to read address 0x6b4020 in my application? .tbss contents or .init_array pointers? Why?
The virtual address of .tbss is meaningless as that section only serves as a template for the TLS storage as allocated by the threading implementation in GLIBC.
The way this virtual address comes into place is that .tbss follows .tbdata in the default linker script:
...
.gcc_except_table : ONLY_IF_RW { *(.gcc_except_table .gcc_except_table.*) }
/* Thread Local Storage sections */
.tdata : { *(.tdata .tdata.* .gnu.linkonce.td.*) }
.tbss : { *(.tbss .tbss.* .gnu.linkonce.tb.*) *(.tcommon) }
.preinit_array :
{
PROVIDE_HIDDEN (__preinit_array_start = .);
KEEP (*(.preinit_array))
PROVIDE_HIDDEN (__preinit_array_end = .);
}
.init_array :
{
PROVIDE_HIDDEN (__init_array_start = .);
KEEP (*(SORT(.init_array.*)))
KEEP (*(.init_array))
PROVIDE_HIDDEN (__init_array_end = .);
}
...
therefore its virtual address is simply the virtual address of the preceding section (.tbdata) plus the size of the preceding section (eventually with some padding in order to reach the desired alignment). .init_array (or .preinit_array if present) comes next and its location should be determined the same way, but .tbss is known to be so very special, that it is given a deeply hard-coded treatment inside GNU LD:
/* .tbss sections effectively have zero size. */
if ((os->bfd_section->flags & SEC_HAS_CONTENTS) != 0
|| (os->bfd_section->flags & SEC_THREAD_LOCAL) == 0
|| link_info.relocatable)
dotdelta = TO_ADDR (os->bfd_section->size);
else
dotdelta = 0; // <----------------
dot += dotdelta;
.tbss is not relocatable, it has the SEC_THREAD_LOCAL flag set, and it does not have contents (NOBITS), therefore the else branch is taken. In other words, no matter how large the .tbss is, the linker does not advance the location of the section that follows it (also know as "the dot").
Note also that .tbss sits in a non-loadable ELF segment:
Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
LOAD 0x0000000000000000 0x0000000000400000 0x0000000000400000
0x00000000000b1f24 0x00000000000b1f24 R E 200000
LOAD 0x00000000000b2000 0x00000000006b2000 0x00000000006b2000
0x0000000000002288 0x00000000000174d8 RW 200000
NOTE 0x0000000000000158 0x0000000000400158 0x0000000000400158
0x0000000000000044 0x0000000000000044 R 4
TLS 0x00000000000b2000 0x00000000006b2000 0x00000000006b2000 <---+
0x0000000000000020 0x0000000000000060 R 8 |
GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 |
0x0000000000000000 0x0000000000000000 RW 8 |
|
Section to Segment mapping: |
Segment Sections... |
00 .note.ABI-tag ... |
01 .tdata .ctors ... |
02 .note.ABI-tag ... |
03 .tdata .tbss <---------------------------------------------------+
04
This is rather simple if you have an understanding about two things:
1) What is SHT_NOBITS
2) What is tbss section
SHT_NOBITS means that this section occupies no space inside file.
Normally, NOBITS sections, like bss are placed after all PROGBITS sections at the end of the loaded segments.
tbss is special section to hold uninitialized thread-local data that contribute to the program's memory image. Take an attention here: this section must hold unique data for each program thread.
Now lets talk about overlapping. We have two possible overlappings -- inside binary file and inside memory.
1) Binary files offset:
There is no data to write under this section in binary. Inside file it holds no space, so linker start next section init_array immediately after tbss declared. You may think about its size not as about size, but as about special service information for code like:
if (isTLSSegment) tlsStartAddr += section->memSize();
So it doesn't overlap anything inside file.
2) Memory offset
The tdata and tbss sections may be possibly modified at startup time by the dynamic linker
performing relocations, but after that the section data is kept around as the initialization image and not modified anymore. For each thread, including the initial one, new memory is allocated into which then the content of the initialization image is copied. This ensures that all threads get the same starting conditions.
This what makes tbss (and tdata) so special.
Do not think about their memory offsets as about statically known -- they are more like "generation patterns" for per-thread work. So they also can not overlap with "normal" memory offsets -- they are being processed in other way.
You may consult with this paper to know more.
I have a new Computer for 3 Weeks now and i get a lot of WHEA_UNCORRECTABLE_ERROR BSODs.
I get These Bluescreens random every 30 - 50 minutes.
Here is the dump from WinDbg:
Microsoft (R) Windows Debugger Version 6.2.9200.20512 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.
Loading Dump File [C:\Windows\Minidump\050913-7984-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available
Symbol search path is: SRV*c:\Symbole*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows 8 Kernel Version 9200 MP (4 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 9200.16551.amd64fre.win8_gdr.130306-1502
Machine Name:
Kernel base = 0xfffff80104018000 PsLoadedModuleList = 0xfffff801042e4b00
Debug session time: Thu May 9 17:12:45.597 2013 (UTC + 2:00)
System Uptime: 0 days 0:00:25.246
Loading Kernel Symbols
...............................................................
................................................................
..................
Loading User Symbols
Loading unloaded module list
.......
*
Bugcheck Analysis *
*
Use !analyze -v to get detailed debugging information.
BugCheck 124, {0, fffffa8008c87028, be200000, 2110a}
Probably caused by : GenuineIntel
Followup: MachineOwner
1: kd> !analyze -v
*
Bugcheck Analysis *
*
WHEA_UNCORRECTABLE_ERROR (124)
A fatal hardware error has occurred. Parameter 1 identifies the type of error
source that reported the error. Parameter 2 holds the address of the
WHEA_ERROR_RECORD structure that describes the error conditon.
Arguments:
Arg1: 0000000000000000, Machine Check Exception
Arg2: fffffa8008c87028, Address of the WHEA_ERROR_RECORD structure.
Arg3: 00000000be200000, High order 32-bits of the MCi_STATUS value.
Arg4: 000000000002110a, Low order 32-bits of the MCi_STATUS value.
Debugging Details:
BUGCHECK_STR: 0x124_GenuineIntel
CUSTOMER_CRASH_COUNT: 1
DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT
PROCESS_NAME: System
CURRENT_IRQL: f
STACK_TEXT:
fffff880009f9868 fffff8010479193d : 0000000000000124 0000000000000000 fffffa8008c87028 00000000be200000 : nt!KeBugCheckEx
fffff880009f9870 fffff80104178969 : 0000000000000001 fffffa80066d7320 0000000000000000 fffffa8008c87028 : hal!HalBugCheckSystem+0xf9
fffff880009f98b0 fffff801047916e3 : 0000000000000728 0000000000000001 fffff880009f9a10 fffffa80066d7320 : nt!WheaReportHwError+0x249
fffff880009f9910 fffff8010479100c : 0000000000000010 fffffa80066d7320 fffff880009f9ac8 fffffa80066d7320 : hal!HalpMcaReportError+0x53
fffff880009f9a70 fffff80104790f07 : fffffa800678b760 0000000000000001 0000000000000001 0000000000000000 : hal!HalpMceHandlerCore+0xd4
fffff880009f9ac0 fffff80104790d64 : 0000000000000004 0000000000000001 0000000000000000 0000000000000000 : hal!HalpMceHandler+0xe3
fffff880009f9b00 fffff80104791edb : fffffa800678b760 fffff880009f9d30 0000000000000000 0000000000000000 : hal!HalpMceHandlerWithRendezvous+0xd4
fffff880009f9b30 fffff8010407057b : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : hal!HalHandleMcheck+0x40
fffff880009f9b60 fffff8010407032e : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : nt!KxMcheckAbort+0x7b
fffff880009f9ca0 fffff8800158e984 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : nt!KiMcheckAbort+0x16e
fffff88002e1b888 0000000000000000 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : intelppm!MWaitIdle+0x18
STACK_COMMAND: kb
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: GenuineIntel
IMAGE_NAME: GenuineIntel
DEBUG_FLR_IMAGE_TIMESTAMP: 0
FAILURE_BUCKET_ID: 0x124_GenuineIntel_PROCESSOR_CACHE
BUCKET_ID: 0x124_GenuineIntel_PROCESSOR_CACHE
Followup: MachineOwner
I have also reinstalled Windows 3 times now but every time i get These Errors.
Can anyone tell me whats the Problem is?
Greets
This might cause by INTEL CPU driver, for energy management or etc. try not to install intel cpu driver(might delivered with motherboard).
I have tried both "arm-none-eabi-gcc" and "arm-elf-gcc" installed via MacPorts, but every time I compile, I get this warning.
ld: warning: cannot find entry symbol _start; defaulting to 0000000000008000
I am using the "-T" flag and specifying my own linker file which is as follows.
SECTIONS {
. = 0x00000000;
.text : { * (vectors); * (.text); }
.rodata : { * (.rodata); }
text_end = .;
. = 0xA4000000;
.data : AT (text_end) { * (.data); }
.bss : { * (.bss); }
}
NM dumps this.
00000000 t reset
00000004 t undefined
00000008 t swi
0000000c t prefetch_abort
00000010 t data_abort
00000014 t reserved
00000018 t interrupt_request
0000001c t fiq
00000020 t irq
00000024 T init
00000038 T main
0000004c A text_end
00008024 t entry
0000804c T __data_start
00010028 A __bss_end__
00010028 A __bss_start
00010028 A __bss_start__
00010028 A __end__
00010028 A _bss_end__
00010028 A _edata
00010028 A _end
00080000 N _stack
Linker is giving you a warning because it is not able to find a _start symbol in compiled code. And your current linker configuration is expecting that there should be such symbol defined somewhere in the code.
So you either have solution to manually define your entry point (i.e. reset) by consulting the compiler/linker user manual and understanding the usage of -e linker flag or really define a symbol named _start in some of your code.