Why does GDB need the executable as well as the core dump?
The core dump is just the dump of your programs memory footprint, if you know where everything was then you could just use that.
You use the executable because it explains where (in terms of logical addresses) things are located in memory, i.e. the core file.
If you use a command objdump it will dump the meta data about the executable object you are investigating.
Using an executable object named a.out as an example.
objdump -h a.out dumps the header information only, you will see sections named eg. .data or .bss or .text (there are many more). These inform the kernel loader where in the object various sections can be found and where in the process address space the section should be loaded, and for some sections (eg .data .text) what should be loaded. (.bss section doesn't contain any data in the file but it refers to the amount of memory to reserve in the process for uninitialised data, it is filled with zeros ).
The layout of the executable object file conforms to a standard, ELF.
objdump -x a.out - dumps everything
If the executable object still contains its symbol tables (it hasn't been stripped - man strip and you used -g to generate debug generation to gcc
assuming a c source compilation), then you can examine the core contents by symbol names, e.g. if you had a variable/buffer named inputLine in your source code, you could use that name in gdb to look at its content. i.e. gdb would know the offset from the start of your programs initialised data segment where inputLine starts and the length of that variable.
Further reading Article1, Article 2, and for the nitty gritty Executable and Linking Format (ELF) specification.
Update after @mirabilos comment below.
But if using the symbol table as in
$ gdb --batch -s a.out -c core -q -ex "x buf1"
Produces
0x601060 <buf1>: 0x72617453
and then not using symbol table and examining address directly in,
$ gdb --batch -c core -q -ex "x 0x601060"
Produces
0x601060: 0x72617453
I have examined memory directly without using the symbol table in the 2nd command.
I also see, @user580082 's answer adds further to explanation, and will up-vote.
The core file is a snapshot of the stack image, memory mappings and registers at the time of process termination. The contents of which can be manipulated as given in core man page. By default private mappings, shared mappings and ELF header information is dumped into core file.
Coming to your question, the reason that gdb requires executable is because it doesn't simulate the execution, by reading and interpreting the binary instructions like valgrind does instead it becomes the parent of the process so as to control the behavior of the process during run time. It uses the core file to determine the memory mappings and processor state of process during crash.
In Linux parent processes can get additional information about their children, in particular the ability to ptrace them which allow the debugger to access process's low level information like read/write its memory, registers, change signal mappings, stop its execution etc.
You will understand the requirement of executable inspite of having core file more once you read how any debugger works.