When making OMAGIC executables with ld with the swich -N, the ld script begins with : >SECTIONS >{ > . = 0x1020; and so on Which make the executables hopelessly segfault. It seems that giving to ld a script with . = 0x0 corrects the problem. However, I'm unable to find out where to change in the sources.
Hi Quentin, > When making OMAGIC executables with ld with the swich -N, the ld script begins > with : > >> SECTIONS >> { >> . = 0x1020; It does ? The version I have locally starts with ". = 0". > It seems that giving to ld a script with . = 0x0 corrects the problem. However, > I'm unable to find out where to change in the sources. The linker scripts are built by the genscripts.sh script in the linker source directory. They are constructed into the ldscripts/ directory in the build tree and the script for the -N switch will have the extension .xbn. The scripts are build from a template in the ld/scripttempl/ source directory, together with information from a parameters file in ld/emulparam/ source directory. For the i486-aout target these should be the ld/scripttempl/aout.sc file and the ld/emulparams/i386aout.sh. The start address should then be controlled by the value given to the TEXT_START_ADDR shell variable. Cheers Nick
As Nick says, current x86-aout scripts have . = 0.
In binutils 2.17 sources, What I see in emulparams/i386linux.sh is : >OUTPUT_FORMAT="a.out-i386-linux" >TARGET_PAGE_SIZE=0x1000 >TEXT_START_ADDR=0x1020 >NONPAGED_TEXT_START_ADDR=0 >... and in genscripts.sh >... >LD_FLAG=N >DATA_ALIGNMENT=${DATA_ALIGNMENT_N} >( echo "/* Script for -N: mix text and data on same page; don't align data */" > . ${CUSTOMIZER_SCRIPT} ${EMULATION_NAME} > . ${srcdir}/scripttempl/${SCRIPT_NAME}.sc >) | sed -e '/^ *$/d;s/[ ]*$//' > ldscripts/${EMULATION_NAME}.xbn >... In the building process the section SECTION is going to start at 0x1020 for the -N flag. (I see no mention of NONPAGED_TEXT_START_ADDR in scripttempl/aout.sc) I checked, on a up to date Debian, the output from ld -N -mi386linux --verbose gives out a >SECTIONS >{ > . = 0x1020; >...
Oops. Indeed, i486-linux-aout has this problem. Both Nick and I checked i486-aout, assuming that it was the same target as i486-linux-aout.
typo.. i486-linuxaout. i486-linux-aout is the same as i486-aout.
http://sourceware.org/ml/binutils-cvs/2007-08/msg00055.html applied to 2.18 branch too.