The version I used to do the test was a pretty recent version and assume that 3420924 was already part of that. To be sure I just ran the same experiment again with the latest that is available for windows as a binary (mspgcc-20120125-experimental.zip) and the result is the same. Anyways, I have filed a bug report: 3490473
I also noticed that when inspecting the .elf file with msp430-nm the symbol main is not present in the no blinky elf file (as expected). The working elf file does have the symbol main (as expected). Not sure of the magic going in the background but to me it seems the linker simply striped main. Anyways, let me know if you need me to try anything else. Robert ----- Original Message ----- From: Peter Bigot <big...@acm.org> To: Michael Richardson <m...@sandelman.ca> Cc: Robert Wessels <robertin...@yahoo.com>; "mspgcc-users@lists.sourceforge.net" <mspgcc-users@lists.sourceforge.net> Sent: Tuesday, February 21, 2012 8:05 AM Subject: Re: [Mspgcc-users] main as part of an archive created with msp430-ar On Tue, Feb 21, 2012 at 9:48 AM, Michael Richardson <m...@sandelman.ca> wrote: > >>>>>> "Peter" == Peter Bigot <big...@acm.org> writes: > Peter> see if I can figure something out. My patience with this feature is > Peter> about at its end, though, so the solution may be to stop > Peter> treating main > Peter> as special unless the user adds the magic fairy dust around the > Peter> declaration that makes it work this way. > > Would the solution be to have _msp_main in the libgcc, as assembly, > and for it to set up the stack and jmp to main? The CRT init* code sets up the stack and does other things before main gets invoked, then the fini* stuff gets run. How main gets invoked is the question. Jumping to it (as opposed to calling it) would still make it special, which is the basic problem. As I recall, the original approach was to have __jump_to_main in .init9, and have main terminate with a jump to __stop_progExec__ in .fini9. main was special: no caller-saved registers, no return operation, end with a jump. The current solution just puts main directly in .init9, letting it fall through to __stop_progExec__ or whatever's in .fini9. main is automatically marked "naked", but is otherwise the same as any other naked function (no "jump to wherever" added to it). If I were to change this, there'd be a _main or __main in .init9 that does nothing but call main then fall through to .fini9. main would no longer be special. Determining the appropriate name for the stub that calls main would require research. The current behavior could be obtained by renaming the user function _main and marking it naked. But I'm pretty sure the problem in this case is the lack of the referenced patch, so I'm not likely to do this. Fixing the gdb issue 3420924 (whenever I get to that) will probably be less effort/impact. Peter > -- > ] He who is tired of Weird Al is tired of life! | firewalls > [ > ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net > architect[ > ] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device > driver[ > Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE> > then sign the petition. ------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ _______________________________________________ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
