OSDev.org

Posted: **Mon Jun 29, 2015 9:20 pm**

I have run across a new wrinkle. The scenario is that I have been building and running a 32 bit binary as part of the loader, some snippets to indicate what was successful.

the linker script fragment

Code: Select all

SECTIONS
{

    .text 	0x0000F400 :
    {
        code = .; _code = .; __code = .;
        *(.text)
        . = ALIGN(1024);
    }

the method fragment

Code: Select all

extern "C"
{
void plugin_main	(hubris::system::plugin::config_t* config,int index)
{
...
}
}

the disassembly of the gen_pm_plugin.bin fragment

Code: Select all

00000000  55                push bp
00000001  89E5              mov bp,sp
00000003  81EC9801          sub sp,0x198
00000007  0000              add [bx+si],al
00000009  83EC0C            sub sp,byte +0xc
...

map file fragment showing that the entry point is where the linker script defined it should be

Code: Select all

 .text          0x000000000000f400      0x512 gen_pm_plugin.o
                0x000000000000f400                plugin_main

When I include a lambda usage within the method like so

Code: Select all

extern "C"
{
void plugin_main	(hubris::system::plugin::config_t* config,int index)
{
...
	header.programEntryForall
			(	[]
				(hubris::module::format::elf::ProgramEntry32* member) ->void
				{
					member->prepare();
				}
			);
}
}

I get the following disassembly fragement which shows some additional instruction which do nothing really except return to the loader which is unexpected.

Code: Select all

00000000  55                push bp
00000001  89E5              mov bp,sp
00000003  90                nop
00000004  5D                pop bp
00000005  C3                ret

and the new map fragment showing that the entry point has been moved and differs from the location specified in the linker script.

Code: Select all

 .text          0x000000000000f400      0x79a gen_pm_plugin.o
                0x000000000000f406                plugin_main

These additional instructions only appear when I use a lambda, if I substitute a call to another method it continues to work as expected.

So the question is why the change given the linker script has not changed and yet the start location is moved inwards by the additional 6 bytes which are these mystery instructions.

I can work around the issue by jumping the 6 bytes but this is a fragile solution and I would like to understand why the additional instructions are appearing.

Posted: **Tue Jun 30, 2015 12:13 am**

hubris wrote:

Code: Select all

00000000  55                push bp
00000001  89E5              mov bp,sp
00000003  81EC9801          sub sp,0x198
00000007  0000              add [bx+si],al
00000009  83EC0C            sub sp,byte +0xc
...

Isn't this 32-bit code? Why are you disassembling it as 16-bit code?

hubris wrote:and the new map fragment showing that the entry point has been moved and differs from the location specified in the linker script.

Where in your linker script do you specify the entry point? I don't see anything like that in the fragment you posted.

OSDev.org

i686-elf-xxx injecting prolog instructions for lambda why?

i686-elf-xxx injecting prolog instructions for lambda why?

Re: i686-elf-xxx injecting prolog instructions for lambda wh