Re: naked function attribute support for Mips

[Chung-Ju Wu]

2013/5/3 Chung-Ju Wu :
>
> Or do you think 'naked' is still useful for some other cases in mips porting?
> You can implement it and submit the patch to gcc-patc...@gcc.gnu.org
> and I believe the mips maintainers are willing to have review with you. :)
>

Oops~ I just noticed that the mips maintainer Richard Sandiford
already had some thought about 'naked' attribute.

Refer to:
http://gcc.gnu.org/ml/gcc-patches/2008-10/msg00660.html


Best regards,
jasonwucj

Re: naked function attribute support for Mips

[reed kotler]

On 05/03/2013 01:06 AM, Chung-Ju Wu wrote:

2013/5/3 Chung-Ju Wu :

Or do you think 'naked' is still useful for some other cases in mips porting?
You can implement it and submit the patch to gcc-patc...@gcc.gnu.org
and I believe the mips maintainers are willing to have review with you. :)


Oops~ I just noticed that the mips maintainer Richard Sandiford
already had some thought about 'naked' attribute.

Refer to:
http://gcc.gnu.org/ml/gcc-patches/2008-10/msg00660.html


Best regards,
jasonwucj

I think are many valid uses for the naked attribute.

Here is a simple example:

void foo() __attribute__((naked));

void foo() {
#ifdef DEBUG
   C code
#else
   Production code in assembly
#endif
}


You may have a very different implementation of several or many 
functions when the production mode is present but for purely debugging 
logic, some C code could be there.


The main idea is that "naked" is there for someone that needs it.

The caller/callee saved register issue is there. In the absence of 
additional function attributes, one would presume that normal abi rules 
apply. But this issue is there even if you use assembly code instead of 
functions with the naked attribute.

DWARF2 offset for local variables

[BELBACHIR Selim]

Hi,

I'm (still) working on a new gcc-4.5.2 backend for a private processor.
Today i'm concerned about the debug mode using DWARF2.

Here is my problem:
When I use GDB on a executable compiled with -g option I notice that the 
addresses of all my local variables are wrong.
I read gccint doc and tried to use DEBUGGER_AUTO_OFFSET(X) and 
DEBUGGER_ARG_OFFSET(OFFSET, X) but I noticed (thanks to printf) that they were 
never called for DWARF2. (I saw afterward that dwarf2out.c did not use these 
macros)

My stack frame is organized as follow :

Hi mem Address |   |
   +---+ <= $SP before prologue
   |   |
   | Reg save  |
   |   |
   +---+
   |   |
   |  Locals / Temps   |
   |   |
   +---+
   |   |
   |Args Block |
   |   |
   +---+ <= $SP after prologue
Lo mem Address |   |
  

With 

#define STACK_GROWS_DOWNWARD 1
#define FRAME_POINTER_CFA_OFFSET(FNDECL) 0
#define STARTING_FRAME_OFFSET crtl->outgoing_args_size
#define FIRST_PARM_OFFSET(FUNDECL) 0
#define DWARF2_DEBUGGING_INFO
#define PREFERRED_DEBUGGING_TYPE DWARF2_DEBUG  
#define ELIMINABLE_REGS \
  {{HARD_FRAME_POINTER_REGNUM, STACK_POINTER_REGNUM}, \
   {FRAME_POINTER_REGNUM, STACK_POINTER_REGNUM}, \
   {FRAME_POINTER_REGNUM, HARD_FRAME_POINTER_REGNUM}, \
   {ARG_POINTER_REGNUM, STACK_POINTER_REGNUM}, \
   {ARG_POINTER_REGNUM, HARD_FRAME_POINTER_REGNUM}, \
  }
#define INITIAL_ELIMINATION_OFFSET(FROM, TO, OFFSET) \
  (OFFSET) = my_initial_elimination_offset ((FROM), (TO))


HOST_WIDE_INT my_initial_elimination_offset (int from, int to ATTRIBUTE_UNUSED)
{
  HOST_WIDE_INT offset;
  switch (from)
  {
  case HARD_FRAME_POINTER_REGNUM:
offset = 0;
break;
  case FRAME_POINTER_REGNUM:
offset = 0;
break;
  case ARG_POINTER_REGNUM:
offset = my_stack_frame_size();
break;
  default:
gcc_unreachable ();
  }
  return offset;
}


How can I express an offset for local variables in DWARF2 for GDB ?


Regards,

Selim Belbachir

Re: naked function attribute support for Mips

[Richard Sandiford]

Glad to see the push-back on this :-)

reed kotler  writes:
> On 05/03/2013 01:06 AM, Chung-Ju Wu wrote:
>> 2013/5/3 Chung-Ju Wu :
>>> Or do you think 'naked' is still useful for some other cases in mips 
>>> porting?
>>> You can implement it and submit the patch to gcc-patc...@gcc.gnu.org
>>> and I believe the mips maintainers are willing to have review with you. :)
>>>
>> Oops~ I just noticed that the mips maintainer Richard Sandiford
>> already had some thought about 'naked' attribute.
>>
>> Refer to:
>> http://gcc.gnu.org/ml/gcc-patches/2008-10/msg00660.html
>>
>>
>> Best regards,
>> jasonwucj
> I think are many valid uses for the naked attribute.
>
> Here is a simple example:
>
> void foo() __attribute__((naked));
>
> void foo() {
> #ifdef DEBUG
> C code
> #else
> Production code in assembly
> #endif
> }
>
>
> You may have a very different implementation of several or many 
> functions when the production mode is present but for purely debugging 
> logic, some C code could be there.

I'm not convinced -- does anyone actually do this?  If so, do they do it
for performance reasons?  It would be bad if the compiler's output was
so poor that this was necessary.  Plus it prevents any kind of LTO,
which seems strange for a routine that is presumably performance-critical.
E.g. it stops the compiler from generating specialised clones, or from
inlining part of the function and leaving the rest out-of-line.

This is pedantic, but: in your example, the attribute should only be
used in the "production code" case.  So in practice the whole function
definition would be guarded by the #ifdef, with the attribute in the
production arm but not in the debug arm.  In which case why not use
a .S file?  It's surely nicer than having to write a (presumably
relatively large) asm function as a C string.

You say that naked attributes "just work".  But the problem is that
corner cases keep cropping up.  Your return question is a good example.
My understanding is that the compiler should never generate any code
itself for a naked function, and that naked functions must be an asm and
nothing else.  In particular, naked functions must not have a return statement.

It's tempting to see:

  int __attribute__((naked))
  foo (void)
  {
asm ("");
  }

as a normal function in which the compiler just happens not generate
any prologue and epilogue code.  But its reach is far wider than that.
See e.g.:

  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53633

where the compiler must assume that the asm returns, which is something
normal asms are not allowed to do.  Another difference is that normal
asms must list the registers that they clobber (except for the usual
MIPS rule that asms can clobber $1).  E.g. for:

  int
  foo (int x)
  {
asm ("# foo");
return x;
  }

the compiler is free to assume that the asm clobbers neither $2 nor $4,
and so we get:

foo:
move$2,$4
# foo
j   $31

But the asm in a naked function is different, because we have to assume
that the asm can change any call-clobbered register.  This matters if
you're doing IPA to figure out which functions happen to preserve which
"call-clobbered" registers (so that callers can treat them as call-saved
instead).  Naked functions would be a special case that's easily forgotten.

Then there are questions like: what .cfi_* directives, if any, should
the compiler generate for a naked function?  Should it generate the
.cfi_startproc and .cfi_endproc, or is that the asm's job?  The answer
isn't really obvious.

That's just a list from the top of my head, I doubt it's exhaustive. :-)

Richard

Re: naked function attribute support for Mips

[Richard Biener]

On Fri, May 3, 2013 at 12:29 PM, Richard Sandiford
 wrote:
> Glad to see the push-back on this :-)
>
> reed kotler  writes:
>> On 05/03/2013 01:06 AM, Chung-Ju Wu wrote:
>>> 2013/5/3 Chung-Ju Wu :
 Or do you think 'naked' is still useful for some other cases in mips 
 porting?
 You can implement it and submit the patch to gcc-patc...@gcc.gnu.org
 and I believe the mips maintainers are willing to have review with you. :)

>>> Oops~ I just noticed that the mips maintainer Richard Sandiford
>>> already had some thought about 'naked' attribute.
>>>
>>> Refer to:
>>> http://gcc.gnu.org/ml/gcc-patches/2008-10/msg00660.html
>>>
>>>
>>> Best regards,
>>> jasonwucj
>> I think are many valid uses for the naked attribute.
>>
>> Here is a simple example:
>>
>> void foo() __attribute__((naked));
>>
>> void foo() {
>> #ifdef DEBUG
>> C code
>> #else
>> Production code in assembly
>> #endif
>> }
>>
>>
>> You may have a very different implementation of several or many
>> functions when the production mode is present but for purely debugging
>> logic, some C code could be there.
>
> I'm not convinced -- does anyone actually do this?  If so, do they do it
> for performance reasons?  It would be bad if the compiler's output was
> so poor that this was necessary.  Plus it prevents any kind of LTO,
> which seems strange for a routine that is presumably performance-critical.
> E.g. it stops the compiler from generating specialised clones, or from
> inlining part of the function and leaving the rest out-of-line.
>
> This is pedantic, but: in your example, the attribute should only be
> used in the "production code" case.  So in practice the whole function
> definition would be guarded by the #ifdef, with the attribute in the
> production arm but not in the debug arm.  In which case why not use
> a .S file?  It's surely nicer than having to write a (presumably
> relatively large) asm function as a C string.
>
> You say that naked attributes "just work".  But the problem is that
> corner cases keep cropping up.  Your return question is a good example.
> My understanding is that the compiler should never generate any code
> itself for a naked function, and that naked functions must be an asm and
> nothing else.  In particular, naked functions must not have a return 
> statement.
>
> It's tempting to see:
>
>   int __attribute__((naked))
>   foo (void)
>   {
> asm ("");
>   }
>
> as a normal function in which the compiler just happens not generate
> any prologue and epilogue code.  But its reach is far wider than that.
> See e.g.:
>
>   http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53633
>
> where the compiler must assume that the asm returns, which is something
> normal asms are not allowed to do.  Another difference is that normal
> asms must list the registers that they clobber (except for the usual
> MIPS rule that asms can clobber $1).  E.g. for:
>
>   int
>   foo (int x)
>   {
> asm ("# foo");
> return x;
>   }
>
> the compiler is free to assume that the asm clobbers neither $2 nor $4,
> and so we get:
>
> foo:
> move$2,$4
> # foo
> j   $31
>
> But the asm in a naked function is different, because we have to assume
> that the asm can change any call-clobbered register.  This matters if
> you're doing IPA to figure out which functions happen to preserve which
> "call-clobbered" registers (so that callers can treat them as call-saved
> instead).  Naked functions would be a special case that's easily forgotten.
>
> Then there are questions like: what .cfi_* directives, if any, should
> the compiler generate for a naked function?  Should it generate the
> .cfi_startproc and .cfi_endproc, or is that the asm's job?  The answer
> isn't really obvious.
>
> That's just a list from the top of my head, I doubt it's exhaustive. :-)

I agree with all of this.  For LTO we need a way to annotate toplevel
asm()s with the symbols they require and provide, so a naked function
foo would just become

int foo (int);
asm("." : : : : );

which is much cleaner - it is then really embedding a .S file into
the TU (for whatever reason, one being the ability to make foo .local).

Richard.

Re: Why include header file in for FreeBSD >= 5 ?

[Zachary Jude]

Thanks Ian.

Following the link provided by you, I have learned how stddef.h
changed to adapt the  which first came at
FreeBSD 5.

The main change that affects  from  to
 was explained at

http://gcc.gnu.org/ml/gcc/2002-09/msg00560.html

What still confuse me is that  doesn't define foo_t by using
__foo_t which is defined in either  or
 (mentioned at the link above), the following two
links is the corresponding file:

http://svnweb.freebsd.org/base/release/5.5.0/sys/sys/_types.h?view=co

http://svnweb.freebsd.org/base/release/5.5.0/sys/i386/include/_types.h?view=co

Instead, the  uses __FOO_TYPE__ macro to define foo_t, so
what makes it necessary to let  include  in
FreeBSD >= 5 ?

I know  will check and define _FOO_T_DECLARED macro which is
required by FreeBSD >= 5 in order to claim that foo_t has been
declared, but this is not necessarily need to include ,
right?

--
Zachary

2013/5/3 Ian Lance Taylor :
> On Thu, May 2, 2013 at 3:32 AM, Zachary Jude  wrote:
>>
>> I'm figuring out the code in
>>
>> /usr/lib/gcc/x86_64-redhat-linux/4.1.1/include/stddef.h,
>>
>> and I saw the macro switch below:
>>
>> #if defined (__FreeBSD__) && (__FreeBSD__ >= 5)
>> #include 
>> #endif
>>
>> I have gone through all the 、 and
>>  source files for the whole 5.X.X version of
>> FreeBSD, and still can't find anything may affect the behavior of code
>> below that macro switch in .
>>
>> Can someone please help in figuring out this ?
>
> I'm sure you are aware that 4.1.1 is quite old at this point.
>
> That code was added by this patch:
> http://gcc.gnu.org/ml/gcc-patches/2002-10/msg3.html .  Perhaps
> that will help explain what is going on here.
>
> Ian

Re: naked function attribute support for Mips

[David Brown]

On 03/05/13 10:06, Chung-Ju Wu wrote:
> 2013/5/3 Chung-Ju Wu :
>>
>> Or do you think 'naked' is still useful for some other cases in mips porting?
>> You can implement it and submit the patch to gcc-patc...@gcc.gnu.org
>> and I believe the mips maintainers are willing to have review with you. :)
>>
> 
> Oops~ I just noticed that the mips maintainer Richard Sandiford
> already had some thought about 'naked' attribute.
> 
> Refer to:
> http://gcc.gnu.org/ml/gcc-patches/2008-10/msg00660.html
> 

I've only used gcc on mips for a couple of small programs, and haven't
needed "naked".  But I've used it occasionally on other targets, and I'm
with Mark Mitchell on this one.  "naked" is not often useful - but when
it /is/ useful, it can be very useful.  In some cases you might want to
use it for interrupts, if the normal interrupt framing is not suitable
(on some platforms it is not quite optimal).  You might want to use it
in conjunction with writing a RTOS.

Personally, I've used "naked" when I want to write pure assembly code
and don't want extra stack frames or "return" codes.  I don't want to
write stand-alone assembly files (I've written mountains of them in the
past, and hope they stay in the past).  I am happier using the very nice
flexible gcc inline assembly syntax.  I am happier having all my code in
C files - it fits my build process well.

So some people use "naked" on some targets.  Other people who don't like
it, don't have to use it.  But in the interests of compatibility,
maintainability, code re-use (within gcc), ease of use, code re-use by
users across different platforms, ease of learning, simpler
documentation, and a dozen other good reasons - there should always be
an aim to make attributes consistent across targets.  I can well
understand that some attributes will not be implemented on some targets
- they are perhaps not appropriate, or there simply has not been anyone
with the time to do the work.  But - speaking purely as a user - it is
hard to understand why a feature like "naked" would not be available on
all targets.

Equally, it is hard to comprehend why attributes for interrupt functions
are called "interrupt" on one target, "interupt_handler" on another, and
"exception_handler" on a third - and why "interrupt" will re-enable
interrupts on some targets but not others.

Surely it would be a good thing all round if these sorts of this were -
where practically possible - consistent across targets?

Re: return statement in a function with the naked attribute

[David Brown]

On 03/05/13 06:40, Geert Bosch wrote:
> 
> On May 3, 2013, at 00:15, reed kotler  wrote:
> 
>> There was some confusion on the llvm list because some tests were run on 
>> targets that did not support the naked attribute.
>>
>> I think we are thinking now that the return statement should not be emitted 
>> unless explicitly requested.
>>
>> It's not totally clear in the gcc manual so that is why I was asking.
> 
> I clearly is an error to have a function that doesn't return.

That is certainly not true.

In the world of application programming, functions will typically
return.  But in low-level systems programming and embedded systems
programming, there are a number of times when a function will not
return.  There is a gcc attribute "noreturn" to make that explicit.

Typical cases include the main loop of an embedded system (which
normally never exits), main loops in threads, and functions that exit in
an odd way (such as by starting a new program, reseting the system,
doing a longjmp).

When you use the "naked" attribute, you are telling the compiler that
you know exactly what you are doing, and it should give you exactly what
you ask for - and no more.  You are writing in assembly - if you want
the function to return, you write "ret" - or "reti" or whatever
variation of "return" is appropriate.  You don't want the compiler to
guess and pick the return form it thinks might fit.

There are also cases when you want assembly code that runs off the end,
without returning - you use sections along with a linker script to tie
them all together without calls and returns.  In such code, an
unexpected return would be a disaster.

For an example of such usage, see this section of the AVR gcc port
documentation:






> So, what you really asking is: "What are the semantics of a (naked)
> functon that doesn't return?"
> 
> I think it would make sense for a compiler to emit a special error-return
> (such as abort()) at the end of such a function, with the expectation that
> this code usually would be unreachable and optimized away.
> 
> I don't think it makes sense to try and define any other semantics
> for a funciotn that doesn't explicitly return a value. 
> 

Re: return statement in a function with the naked attribute

[David Brown]

On 03/05/13 06:03, reed kotler wrote:
> On 05/02/2013 08:41 PM, Chung-Ju Wu wrote:
>> 2013/5/3 reed kotler :
>>> Should a return statement be emitted in a function that has the naked
>>> attribute.
>>>
>>> There seems to be some confusion here and apparently disagreement
>>> between
>>> various
>>> gcc compilers.
>>>
>> IMHO, it depends on how you define the word 'naked' for a function
>> and how you expect one writing functions with 'naked' attribute.
>>
>> If you think one is supposed to have *complete* control in the function
>> (i.e. only inline assembly code, without using any C statement and
>> variables),
>> then the asm 'ret' can be omitted.  Porgrammers must explicitly
>> emit 'ret' in the inline asm.
>>
>> If you allow user using C statement in the function with 'naked'
>> attribute,
>> the asm 'ret' is still required.  Because compiler may produce a branch
>> to the epilogue position where 'ret' is expected to exist.
>>
>> AFAIK, there is no standard defining what 'naked' behavior should be.
>> So gcc leaves it to back-end developers.
>>
>>
>> Best regards,
>> jasonwucj
> I think that the compiler should respect any return statements you
> explicitly enter, but should not create any that are implied as in
> reaching the end of the function.
> 

100% agreed.

It is good to allow C code in "naked" functions - but the user must
obviously be aware of what they can and cannot do.  Anything using a
stack frame is right out, for example.

BImode and STORE_VALUE_FLAG

[Paulo Matos]

Hello,

It seems to me there's a bug in 
simplify_const_relational_operation:simplify-rtx.c.
If you set STORE_VALUE_FLAG to -1, if you get to 
simplify_const_relational_operation with code: NE, mode: BImode, op0: reg, op1: 
const_int 0, then you end up in line 4717 calling get_mode_bounds.

get_mode_bounds will unfortunately return min:0, max:-1 for BImode and GCC 
proceeds to compare val which is 0 using:
/* x != y is always true for y out of range.  */
  if (val < mmin || val > mmax)
return const_true_rtx;

This simplifies the comparison to const_true_rtx in the case STORE_FLAG_VALUE 
is -1. This seems flawed. 

Unless there's some background reason for this to happen this seems like a bug. 
BImode is a two value mode: 0 or STORE_FLAG_VALUE (according to 
trunc_int_to_mode), therefore there are really no bounds and these comparisons 
in simplify_const_relational_operation should take special care if dealing with 
BImode. Also, having max < min is strange at best and I can imagine it can 
result in pretty strange behaviour if a developer assumes max >= min, as usual.

I am interested in comments to this piece of code. I am happy to patch 
simplify_const_relational_operation if you agree with what I said.

Cheers,

Paulo Matos

Re: naked function attribute support for Mips

[Richard Sandiford]

David Brown  writes:
> Personally, I've used "naked" when I want to write pure assembly code
> and don't want extra stack frames or "return" codes.  I don't want to
> write stand-alone assembly files (I've written mountains of them in the
> past, and hope they stay in the past).  I am happier using the very nice
> flexible gcc inline assembly syntax.

The full inline asm syntax, such as:

   asm ("..." : "=r" (result) : "i" (100))

is specifically forbidden in naked functions, because in general GCC can
only satisfy the constraints by building its own frame:

  Use this attribute on the ARM, AVR, MCORE, RX and SPU ports to indicate that
  the specified function does not need prologue/epilogue sequences generated by
  the compiler.  It is up to the programmer to provide these sequences. The
  only statements that can be safely included in naked functions are
  @code{asm} statements _that do not have operands_.  All other statements,
  including declarations of local variables, @code{if} statements, and so
  forth, should be avoided.

(my emphasis).  Naked functions must have a body of the form:

{
  asm ("");
}

i.e. an asm with just a plain string, and no other statements or
local variables.  So you don't really get any more flexibility
by using inline asms over using assembly files.

Thanks,
Richard

Re: naked function attribute support for Mips

[reed kotler]

My general opinion is that to not allow the naked attribute is to 
pontificate over a group of sophisticated gcc users that are fully 
capable of understanding what the naked attribute does. They can read 
the manual and accept the responsibility for using the feature.


The ramifications of the full inline asm syntax as you describe below, 
are 100 times more complex to understand (and implement, test and 
maintain in the compiler) than the naked attribute, and have way more 
complex implications in things like LTO than functions with the naked 
attribute.


People have a lot of reason to want to write assembly code in their C 
program and I don't see why we feel that because we control the 
compiler, that we should be preventing them from doing their job in a 
way that they see fit to do it. Everyone has their own concept of best 
practices and none are 100% the same.


The naked attribute completes "inline assembler". Without it, there are 
things you just can't do.


While this is the gcc list, I can interject that for llvm, I implemented 
mips16 stubs fully by creating high level IR for functions and then 
compiling those functions with the naked attribute.


I think though that more documentation should be provided on the 
attribute (as well as for the non simple forms of inline assembler...!)


Reed

On 05/03/2013 07:03 AM, Richard Sandiford wrote:

David Brown  writes:

Personally, I've used "naked" when I want to write pure assembly code
and don't want extra stack frames or "return" codes.  I don't want to
write stand-alone assembly files (I've written mountains of them in the
past, and hope they stay in the past).  I am happier using the very nice
flexible gcc inline assembly syntax.

The full inline asm syntax, such as:

asm ("..." : "=r" (result) : "i" (100))

is specifically forbidden in naked functions, because in general GCC can
only satisfy the constraints by building its own frame:

   Use this attribute on the ARM, AVR, MCORE, RX and SPU ports to indicate that
   the specified function does not need prologue/epilogue sequences generated by
   the compiler.  It is up to the programmer to provide these sequences. The
   only statements that can be safely included in naked functions are
   @code{asm} statements _that do not have operands_.  All other statements,
   including declarations of local variables, @code{if} statements, and so
   forth, should be avoided.

(my emphasis).  Naked functions must have a body of the form:

{
   asm ("");
}

i.e. an asm with just a plain string, and no other statements or
local variables.  So you don't really get any more flexibility
by using inline asms over using assembly files.

Thanks,
Richard

Re: Inquiry about GCC Summer Of Code project idea.

[Svante Signell]

Hi Fotis,

I finally found my changes made so far for gccgo on a computer suffering
double hard disk crashes. Hopefully most of the changes are available on
the backup I found. As it looks they were not too extensive. I'll send a
patch asap to the bug-hurd list, so you can continue from there (when
you are accepted by Google/GNU)

Good luck,
Svante Signell 

On Fri, 2013-05-03 at 21:23 +0300, Fotis Koutoulakis wrote:
> Hello!
> 
> 
> First of all I would like to thank you everyone for your input. I
> really appreciate it.
> 
> 
> I would also like you to know that I managed to study the material
> that you all have linked to (or that is generally available online on
> the project's wikis of that matter) and I managed to come up with a
> proposal for the project idea that got me hooked in the beginning.
> 
> 
> A link to it can be found
> here: 
> https://google-melange.appspot.com/gsoc/proposal/review/google/gsoc2013/nlightnfotis/1
>  (I hope it is publicly visible, it seems to me it is).
> 
> 
> Of course, I am more than open to comments/criticism as well as
> clarifications.
> 
> 
> Last but not least, I would like to thank you all for your time, as
> well as grab the chance to apologize for my late proposal and my late
> answer.
> 
> 
> Sincerely,
> Fotis Koutoulakis
> 
> 
> On Tue, Apr 30, 2013 at 4:58 PM, Ian Lance Taylor 
> wrote:
> On Tue, Apr 30, 2013 at 6:53 AM, Thomas Schwinge
>  wrote:
> >
> > On 
> I have just
> > updated/posted a
> getcontext/makecontext/setcontext/swapcontext usage
> > analysis.  This might constitute a "road block": the Hurd
> currently does
> > not allow for changing the stack of a process/thread.
>  Implemented a
> > while before TLS/__thread variables came along, we have a
> legacy
> > threadvar mechanism implemented in glibc, which places
> thread-local
> > variables (errno, for example) at the bottom of a thread's
> stack.  Then,
> > when switching the stack of a thread, glibc can't locate
> these anymore,
> > and "bad things" happen.  This threadvar mechanism is
> scheduled to go
> > away (we do implement TLS by now), but when working on that
> I hit "some
> > issues" and have not yet found the time to continue.
> >
> 
> 
> > and
> >  3c878vdyqht3%2Efsf%40kepler%2Eschwinge%2Ehomeip%2Enet%3e>
> > have the details.
> >
> > Now, it seems the GCC Go port is implemented in a way that
> makes
> > extensive use of switching stacks.  So until this threadvar
> issue is
> > resolved, there is probably no way to really proceed with
> the GCC Go port
> > for GNU Hurd -- unless maybe this stack switching could be
> hacked around
> > (Ian?), say, by limiting oneself to not using Goroutines and
> similar
> > "specials", and having a custom/minimal Go runtime startup.
> 
> 
> Go does require switching stacks.  A port of Go that doesn't
> support
> goroutines would be useless--nothing in the standard library
> would
> work.  It might be possible to use pthread_getspecific and
> friends
> instead of TLS.
> 
> Ian
> 
> 
> 
> 
> -- 
> Fotis 'NlightNFotis' Koutoulakis
> 
> 
> - "Non semper aestas erit; venit hiems."
> 

Re: naked function attribute support for Mips

[Reed Kotler]

On 05/03/2013 03:29 AM, Richard Sandiford wrote:

Glad to see the push-back on this :-)

reed kotler  writes:

On 05/03/2013 01:06 AM, Chung-Ju Wu wrote:

2013/5/3 Chung-Ju Wu :

Or do you think 'naked' is still useful for some other cases in mips porting?
You can implement it and submit the patch to gcc-patc...@gcc.gnu.org
and I believe the mips maintainers are willing to have review with you. :)


Oops~ I just noticed that the mips maintainer Richard Sandiford
already had some thought about 'naked' attribute.

Refer to:
http://gcc.gnu.org/ml/gcc-patches/2008-10/msg00660.html


Best regards,
jasonwucj

I think are many valid uses for the naked attribute.

Here is a simple example:

void foo() __attribute__((naked));

void foo() {
#ifdef DEBUG
 C code
#else
 Production code in assembly
#endif
}


You may have a very different implementation of several or many
functions when the production mode is present but for purely debugging
logic, some C code could be there.


I'm not convinced -- does anyone actually do this?  If so, do they do it
for performance reasons?  It would be bad if the compiler's output was
so poor that this was necessary.  Plus it prevents any kind of LTO,
which seems strange for a routine that is presumably performance-critical.
E.g. it stops the compiler from generating specialised clones, or from
inlining part of the function and leaving the rest out-of-line.

This is pedantic, but: in your example, the attribute should only be
used in the "production code" case.  So in practice the whole function
definition would be guarded by the #ifdef, with the attribute in the
production arm but not in the debug arm.  In which case why not use
a .S file?  It's surely nicer than having to write a (presumably
relatively large) asm function as a C string.

You say that naked attributes "just work".  But the problem is that
corner cases keep cropping up.  Your return question is a good example.
My understanding is that the compiler should never generate any code
itself for a naked function, and that naked functions must be an asm and
nothing else.  In particular, naked functions must not have a return statement.

It's tempting to see:

   int __attribute__((naked))
   foo (void)
   {
 asm ("");
   }

as a normal function in which the compiler just happens not generate
any prologue and epilogue code.  But its reach is far wider than that.
See e.g.:

   http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53633


In llvm they have a high level ir instruction called "unreachable".

I can't see why the optimizer cannot just ignore the function.

Why is this naked C assembly function any more relevant to gcc than the 
external assembly file that you are proposing we use instead.


What would be good is to add another set of attributes to define the 
calling convention and caller/callee saved registers. I want to do this 
for llvm. That makes things even better.




where the compiler must assume that the asm returns, which is something
normal asms are not allowed to do.  Another difference is that normal
asms must list the registers that they clobber (except for the usual
MIPS rule that asms can clobber $1).  E.g. for:

   int
   foo (int x)
   {
 asm ("# foo");
 return x;
   }

the compiler is free to assume that the asm clobbers neither $2 nor $4,
and so we get:

foo:
move$2,$4
# foo
j   $31

But the asm in a naked function is different, because we have to assume
that the asm can change any call-clobbered register.  This matters if
you're doing IPA to figure out which functions happen to preserve which
"call-clobbered" registers (so that callers can treat them as call-saved
instead).  Naked functions would be a special case that's easily forgotten.

Then there are questions like: what .cfi_* directives, if any, should
the compiler generate for a naked function?  Should it generate the
.cfi_startproc and .cfi_endproc, or is that the asm's job?  The answer
isn't really obvious.

That's just a list from the top of my head, I doubt it's exhaustive. :-)

Richard

Re: naked function attribute support for Mips

[Reed Kotler]

Microchip which makes the Pic32 embedded processor (Mips32) has the 
naked attribute in their C compiler.



http://ww1.microchip.com/downloads/en/DeviceDoc/51686F.pdf