Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #103776
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: How to find the problem in the object file |
| Date | 2017-02-13 10:21 +0100 |
| Organization | A noiseless patient Spider |
| Message-ID | <o7rtn8$qcq$1@dont-email.me> (permalink) |
| References | (14 earlier) <lno9ybxn52.fsf@kst-u.example.com> <874m03gnc5.fsf@news.bourguet.org> <35f03514-c25d-4372-bbaa-660d78ab7129@googlegroups.com> <lnvasjvtm3.fsf@kst-u.example.com> <7ec2871e-3f58-422e-8382-767774b777d1@googlegroups.com> |
On 10/02/17 01:12, supercat@casperkitty.com wrote:
> On Thursday, February 9, 2017 at 5:19:59 PM UTC-6, Keith Thompson wrote:
>> I believe this program is valid:
>>
>> #include <stdio.h>
>>
>> void func();
>>
>> int main(void) {
>> func("Hello, world");
>> }
>>
>> void func(const char *message) {
>> puts(message);
>> }
>>
>> (The definition could be moved to a different translation unit if that
>> matters.)
>>
>> At the point of the call, the only visible declaration of the function
>> is not a prototype. The function is later defined with a prototype. If
>> different calling conventions were used for prototyped and
>> non-prototyped functions, the call would likely fail somehow.
>
> If the compiler defined entry points for both _func and func, then calls
> to either (using the appropriate convention for the linker name used) would
> work. Having the compiler do so by default, however, would waste a few
> bytes per function unless code actually needed to invoke functions both ways.
> Given that the compiler is designed to support parts with as few as 1024
> bytes, such waste is best avoided. When using default settings, code like
> the above fail with a link error if the function was defined in a different
> compilation unit from where it was called (I think the compiler would also
> issue a warning if a function was declared with a prototype after it had
> already generated code for a call without one). I never had a need to
> request that the compiler generate stubs for both calling conventions, so
> I don't know if it had an option to do so, but it would have been a fairly
> simple way to make the compiler's behavior coincide with the Standard's
> requirements in that regard.
Let me see if I understand your point here, Supercat:
On a compiler for a target like the 8051, it can make sense to have more
optimised calling conventions tuned to the actual parameters used in a
function. For those that don't know the 8051, it is an 8-bit processor
with only a couple of registers, and with extremely poor data stack
support (no "stack pointer + index" addressing modes). So a compiler
for such a target might have a calling convention with "first parameter
in the A register, other parameters on the stack" to be general, and to
work with re-entrant or recursive functions. But given a specific
function "uint8_t foo(uint8_t x, uint8_t y)", that is known to be
non-recursive (through program analysis, command-line options, pragmas,
etc.), it is likely that the compiler will assign static fixed addresses
in memory for "x" and "y".
A general implementation of "foo" would then be:
// Data section
parameter_x: .byte 1
parameter_y: .byte 1
// Code section
foo_unprototyped:
store A at address parameter_x
pop stack into A
store A at address parameter_y
foo_prototyped:
// Use parameter_x and parameter_y
return
Putting data onto the stack, or taking it off the stack, is big and
slow, and avoided where possible.
With an arrangement like this, the compiler will call "foo_prototyped"
when possible and fall back on "foo_unprototyped" when unavoidable.
However, the compiler must always generate both of these entry points
when it generates code for "foo", unless it can be sure that
foo_unprototyped is never used in the code. That could be due to
"static", to whole-program analysis, pragmas, command-line options, etc.
Or it could generate the code and let a smart compiler figure out that
it is not used and remove it.
Either way, as far as C is concerned, the programmer can call the same
function with a prototype declaration or non-prototype declaration, and
get the same effect. Details of the entry point used are hidden by the
implementation.
(Keil is normally used in whole-program mode, I believe, which means
that such things are not only hidden from the programmer, but end up
with the most efficient implementation automatically.)
>
>> The change I propose making to the standard, removing non-prototype
>> function declarations and definitions, needn't affect any non-conforming
>> implementations if, for example, their non-conforming features are
>> sufficiently useful. (I don't know why Keil would use different calling
>> conventions for prototyped and non-prototype functions, but I'll accept
>> that it does so and that there's some reason for it.)
>
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
How to find the problem in the object file Alla _ <modelling.data@gmail.com> - 2017-01-26 05:14 -0800
Re: How to find the problem in the object file BartC <bc@freeuk.com> - 2017-01-26 13:22 +0000
Re: How to find the problem in the object file BartC <bc@freeuk.com> - 2017-01-26 13:37 +0000
Re: How to find the problem in the object file Richard Heathfield <rjh@cpax.org.uk> - 2017-01-26 13:53 +0000
Re: How to find the problem in the object file Alla _ <modelling.data@gmail.com> - 2017-01-26 06:20 -0800
Re: How to find the problem in the object file BartC <bc@freeuk.com> - 2017-01-26 14:28 +0000
Re: How to find the problem in the object file Alla _ <modelling.data@gmail.com> - 2017-01-26 06:48 -0800
Re: How to find the problem in the object file Keith Thompson <kst-u@mib.org> - 2017-01-26 08:29 -0800
Re: How to find the problem in the object file BartC <bc@freeuk.com> - 2017-01-26 16:54 +0000
Re: How to find the problem in the object file luser droog <luser.droog@gmail.com> - 2017-01-26 09:01 -0800
Re: How to find the problem in the object file Keith Thompson <kst-u@mib.org> - 2017-01-26 11:20 -0800
Re: How to find the problem in the object file David Brown <david.brown@hesbynett.no> - 2017-01-26 23:12 +0100
Re: How to find the problem in the object file BartC <bc@freeuk.com> - 2017-01-27 01:32 +0000
Re: How to find the problem in the object file David Brown <david.brown@hesbynett.no> - 2017-01-27 09:50 +0100
Re: How to find the problem in the object file supercat@casperkitty.com - 2017-01-26 09:19 -0800
Re: How to find the problem in the object file Keith Thompson <kst-u@mib.org> - 2017-01-26 11:21 -0800
Re: How to find the problem in the object file Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-02 02:39 -0800
Re: How to find the problem in the object file fir <profesor.fir@gmail.com> - 2017-02-02 04:08 -0800
Re: How to find the problem in the object file fir <profesor.fir@gmail.com> - 2017-02-02 04:31 -0800
Re: How to find the problem in the object file Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-04 10:48 -0800
Re: How to find the problem in the object file fir <profesor.fir@gmail.com> - 2017-02-04 11:07 -0800
Re: How to find the problem in the object file Keith Thompson <kst-u@mib.org> - 2017-02-02 10:22 -0800
Re: How to find the problem in the object file Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-04 11:00 -0800
Re: How to find the problem in the object file Keith Thompson <kst-u@mib.org> - 2017-02-04 14:14 -0800
Re: How to find the problem in the object file Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-04 20:02 -0800
Re: How to find the problem in the object file supercat@casperkitty.com - 2017-02-05 13:39 -0800
Re: How to find the problem in the object file Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-05 13:44 -0800
Re: How to find the problem in the object file Keith Thompson <kst-u@mib.org> - 2017-02-05 13:56 -0800
Re: How to find the problem in the object file Ian Collins <ian-news@hotmail.com> - 2017-02-06 13:07 +1300
Re: How to find the problem in the object file Keith Thompson <kst-u@mib.org> - 2017-02-05 16:14 -0800
Re: How to find the problem in the object file Ian Collins <ian-news@hotmail.com> - 2017-02-06 13:24 +1300
Re: How to find the problem in the object file David Brown <david.brown@hesbynett.no> - 2017-02-06 01:59 +0100
Re: How to find the problem in the object file Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-08 21:32 -0800
Re: How to find the problem in the object file Keith Thompson <kst-u@mib.org> - 2017-02-05 13:54 -0800
Re: How to find the problem in the object file Ian Collins <ian-news@hotmail.com> - 2017-02-06 11:18 +1300
Re: How to find the problem in the object file Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-08 21:32 -0800
Re: How to find the problem in the object file David Brown <david.brown@hesbynett.no> - 2017-02-09 10:33 +0100
Re: How to find the problem in the object file supercat@casperkitty.com - 2017-02-09 09:10 -0800
Re: How to find the problem in the object file Ian Collins <ian-news@hotmail.com> - 2017-02-10 08:01 +1300
Re: How to find the problem in the object file Keith Thompson <kst-u@mib.org> - 2017-02-09 09:01 -0800
Re: How to find the problem in the object file supercat@casperkitty.com - 2017-02-09 09:35 -0800
Re: How to find the problem in the object file Keith Thompson <kst-u@mib.org> - 2017-02-09 09:57 -0800
Re: How to find the problem in the object file Jean-Marc Bourguet <jm@bourguet.org> - 2017-02-09 20:45 +0100
Re: How to find the problem in the object file supercat@casperkitty.com - 2017-02-09 14:59 -0800
Re: How to find the problem in the object file Keith Thompson <kst-u@mib.org> - 2017-02-09 15:20 -0800
Re: How to find the problem in the object file supercat@casperkitty.com - 2017-02-09 16:12 -0800
Re: How to find the problem in the object file David Brown <david.brown@hesbynett.no> - 2017-02-13 10:21 +0100
Re: How to find the problem in the object file supercat@casperkitty.com - 2017-02-13 07:20 -0800
Re: How to find the problem in the object file Keith Thompson <kst-u@mib.org> - 2017-02-13 09:28 -0800
Re: How to find the problem in the object file David Brown <david.brown@hesbynett.no> - 2017-02-13 09:55 +0100
Re: How to find the problem in the object file Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-16 03:36 -0800
Re: How to find the problem in the object file Jean-Marc Bourguet <jm@bourguet.org> - 2017-02-09 20:56 +0100
Re: How to find the problem in the object file Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-16 07:00 -0800
Re: How to find the problem in the object file David Brown <david.brown@hesbynett.no> - 2017-02-16 20:03 +0100
Re: How to find the problem in the object file Ian Collins <ian-news@hotmail.com> - 2017-02-17 09:22 +1300
Re: How to find the problem in the object file Keith Thompson <kst-u@mib.org> - 2017-02-16 13:07 -0800
Re: How to find the problem in the object file Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-24 09:21 -0800
Re: How to find the problem in the object file Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-24 09:02 -0800
Re: How to find the problem in the object file Ian Collins <ian-news@hotmail.com> - 2017-02-25 09:05 +1300
Re: How to find the problem in the object file Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-24 09:26 -0800
Re: How to find the problem in the object file David Brown <david.brown@hesbynett.no> - 2017-02-25 19:38 +0100
Re: How to find the problem in the object file Ian Collins <ian-news@hotmail.com> - 2017-02-03 07:32 +1300
Re: How to find the problem in the object file Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-04 11:24 -0800
Re: How to find the problem in the object file Robert Wessel <robertwessel2@yahoo.com> - 2017-02-02 16:56 -0600
Re: How to find the problem in the object file Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-04 11:12 -0800
Re: How to find the problem in the object file Robert Wessel <robertwessel2@yahoo.com> - 2017-02-06 04:47 -0600
Re: How to find the problem in the object file Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-08 21:59 -0800
Re: How to find the problem in the object file Keith Thompson <kst-u@mib.org> - 2017-02-09 09:13 -0800
Re: How to find the problem in the object file Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-15 19:28 -0800
Re: How to find the problem in the object file Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-24 17:48 -0800
Re: How to find the problem in the object file Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-25 17:36 -0800
Re: How to find the problem in the object file David Brown <david.brown@hesbynett.no> - 2017-01-26 15:51 +0100
Re: How to find the problem in the object file Alla _ <modelling.data@gmail.com> - 2017-01-26 08:29 -0800
Re: How to find the problem in the object file Richard Heathfield <rjh@cpax.org.uk> - 2017-01-26 16:34 +0000
Re: How to find the problem in the object file Alla _ <modelling.data@gmail.com> - 2017-01-26 09:48 -0800
Re: How to find the problem in the object file Keith Thompson <kst-u@mib.org> - 2017-01-26 08:52 -0800
Re: How to find the problem in the object file James Kuyper <jameskuyper@verizon.net> - 2017-01-26 13:53 -0500
Re: How to find the problem in the object file supercat@casperkitty.com - 2017-01-26 11:00 -0800
Re: How to find the problem in the object file David Brown <david.brown@hesbynett.no> - 2017-01-26 23:49 +0100
Re: How to find the problem in the object file Alla _ <modelling.data@gmail.com> - 2017-01-27 06:08 -0800
Re: How to find the problem in the object file David Brown <david.brown@hesbynett.no> - 2017-01-27 16:20 +0100
Re: How to find the problem in the object file Keith Thompson <kst-u@mib.org> - 2017-01-26 08:41 -0800
Re: How to find the problem in the object file m.labanowicz@gmail.com - 2017-01-27 01:26 -0800
csiph-web