GCC GSOC Participation

[Prateek Kalra]

Hello GCC Community,
My name is Prateek Kalra.I am pursuing integrated dual
degree(B.tech+M.tech) in Computer Science Software Engineering,from Gautam
Buddha University,Greater Noida.I am currently in 8th semester of the
programme.
I have experience in competitive programming with C++.Here's my linkedin
profile:
https://www.linkedin.com/in/prateek-kalra-6a40bab3/.
I am interested in GSOC project "Implement a fuzzer leveraging GCC
extensions".
I had opted compiler design as one of the course subjects in the previous
semester and was able to secure an 'A' grade at the end of the semester.
I have theoretical knowledge of fuzz testing and csmith,that how the random
C programs are generated to check the compiler bugs and I am very keen to
work under this project.
I request you to guide me to progress through the process.I would really
appreciate if you could mentor me with the further research of this project
idea.
Regards,
Prateek

Re: MIPS ASAN status? (and "volunteering")

[Hans-Peter Nilsson]

> From: Jean Lee 
> Date: Fri, 2 Mar 2018 13:29:39 +0800

> 2018-03-02 7:53 GMT+08:00 Hans-Peter Nilsson :
> 
> > There's no address-sanitizer support for MIPS (in particular for
> > O32) on trunk, at least not when building for
> > mipsisa32r2el-linux-gnu and libsanitizer/configure.tgt seems
> > to support that observation.  There's a set of patches "floating
> > around", but the last sign of work-in-progress was more than
> > four years ago, according to a well-known search engine.
> >
> > Is there something holding it up getting it into trunk gcc?
> > Is it just that someone needs to go the last mile?
> >
> > I can do that.  I can even go two miles!  Maybe even a merge
> > from compiler-rt and MIPS port hacking (to be merged post
> > gcc-8-branch to trunk, I presume).
> >
> > I'm a little worried that the "patches floating around" have
> > unclear copyright status, so I haven't looked at them yet.  I'd
> > rather not re-do MIPS ASAN on the gcc-side from scratch, but if
> > it comes to that, so be it.
> >
> > brgds, H-P
> >
> 
> It is great to go the last mile. I had done the port  to
> mipsel-linux-uclibc gcc for GCC 4.9/5.0/6.0.
> Maybe I can give some help for you.

That would be great, thanks in advance!

First a few troublesome questions:

Are you the sole copyright owner of the patches to gcc that you
know of?  (Not including compiler-rt patches, those are for the
compiler-rt people to worry about; I don't know their process.)

If so, have you copyright assignment paper work in progress
done or in progress with the FSF for gcc?  (From what I can
tell, if so, it's not completed.)  If not, it'd be great if you
can get that started, it takes quite a while.

I believe that's necessary for gcc-specific parts, but I don't
really decide that.  But, if those patches are small enough to
not requiring paperwork they're probably also uninteresting
enough that I add them as I go by.

> Let's do the last mile.
> To do this, I have some questions.
> Should we port to the upstream LLVM first and port them back to GCC?

I have no interest in LLVM at present, and can't wait, so:
no, not on my behalf.

But the question makes me wonder: are you implying that ASAN
support for MIPS (O32 little-endian) isn't in upstream
Clang/LLVM *too* or do I misunderstand you?  I'm not sure how to
tell myself (save for building it from scratch and trying it,
which I haven't done).

*searches the web again...*

It's not mentioned on
, but that
page seems out-of-date (known working platforms not mentioned).
It's mentioned on
 so
maybe I concluded that since MIPS O32 support is not yet in GCC,
it must have been developed using LLVM.  I thought I saw reviews
for 3+ year accepted patches, but looking closer that must have
been mips64 support.

Thanks again for your support!

brgds, H-P

Re: Why does IRA force all pseudos live across a setjmp call to be spilled?

[Jeff Law]

On 03/02/2018 08:28 PM, Peter Bergner wrote:
> On 3/2/18 3:26 PM, Jeff Law wrote:
>> On 03/02/2018 12:45 PM, Peter Bergner wrote:
>>> ...which forces us to spill everything live across the setjmp by forcing
>>> the pseudos to interfere all hardregs.  That can't be good for performance.
>>> What am I missing?
>>
>> You might want to hold off a bit.  I've got changes for 21161 which can
>> help this significantly.  Basically the live-across-setjmp set is way
>> too conservative -- it includes everything live at the setjmp, but it
>> really just needs what's live on the longjump path.
>>
>> As for why, I believe it's related to trying to make sure everything has
>> the right values if we perform a longjmp.
> 
> I can understand why we might save/restore across functions that can throw
> exceptions since the program state hasn't been saved at the point of the
> call or in the call, but what is special about setjmp()?  We don't need
> to save/restore the volatile regs since all functions clobber them and
> the non-volatile regs are saved/restored by setjmp(), just like any
> normal function call.  ...and as far as I know, setjmp() doesn't save
> or restore the stack contents, just the stack pointer, pc, etc.
> So I guess I still don't know why we treat it differently than any
> other function call wrt register allocation.
Here's the comment from regstat.c:

  /* We have a problem with any pseudoreg that lives
 across the setjmp.  ANSI says that if a user variable
 does not change in value between the setjmp and the
 longjmp, then the longjmp preserves it.  This
 includes longjmp from a place where the pseudo
 appears dead.  (In principle, the value still exists
 if it is in scope.)  If the pseudo goes in a hard
 reg, some other value may occupy that hard reg where
 this pseudo is dead, thus clobbering the pseudo.
 Conclusion: such a pseudo must not go in a hard
 reg.  */

Re: Why does IRA force all pseudos live across a setjmp call to be spilled?

[Peter Bergner]

On 3/3/18 10:29 AM, Jeff Law wrote:
> Here's the comment from regstat.c:
> 
>   /* We have a problem with any pseudoreg that lives
>  across the setjmp.  ANSI says that if a user variable
>  does not change in value between the setjmp and the
>  longjmp, then the longjmp preserves it.  This
>  includes longjmp from a place where the pseudo
>  appears dead.  (In principle, the value still exists
>  if it is in scope.)  If the pseudo goes in a hard
>  reg, some other value may occupy that hard reg where
>  this pseudo is dead, thus clobbering the pseudo.
>  Conclusion: such a pseudo must not go in a hard
>  reg.  */

I can't argue with anything in that comment, other than the conclusion. :-)
It's not the compiler's job to implement the setjmp/longjmp save/restore.
Maybe Kenny was working around a problem with some target's buggy setjmp
and spilling everything "fixed" it?

It is absolutely fine for a pseudo that is live across a setjmp call to
occupy a (non-volatile) hard register at the setjmp's call site, even if
some other value eventually occupies the same hard register between the
setjmp and the longjmp.  The reason is that setjmp saves all of the non-
volatile hard registers in the jmp_buf.  If our pseudo was assigned to
one of those non-volatile hard registers, then its value at the time of
the setjmp call is saved, so even if its hard register is clobbered before
we get to the longjmp call, the longjmp will restore the pseudos value from
the jmp_buf into the hard register, restoring the value it had at the time
of the setjmp call.

The only way I can see the above not working is either setjmp doesn't
save the entire register state it should, the jmp_buf somehow gets clobbered
before the longjmp call or longjmp doesn't restore the entire register
state that it should.  All of those would be bugs in my book.

The only thing the register allocator should need to do, is treat setjmp
just like any other function call and make all pseudos that are live across
it interfere with all volatile hard registers, so that they will be assigned
to either non-volatile hard registers or spilled (if no non-volatile registers
are available).

Peter

Re: Why does IRA force all pseudos live across a setjmp call to be spilled?

[Peter Bergner]

On 3/3/18 5:47 PM, Peter Bergner wrote:
> On 3/3/18 10:29 AM, Jeff Law wrote:
>> Here's the comment from regstat.c:
>>
>>   /* We have a problem with any pseudoreg that lives
>>  across the setjmp.  ANSI says that if a user variable
>>  does not change in value between the setjmp and the
>>  longjmp, then the longjmp preserves it.  This
>>  includes longjmp from a place where the pseudo
>>  appears dead.  (In principle, the value still exists
>>  if it is in scope.)  If the pseudo goes in a hard
>>  reg, some other value may occupy that hard reg where
>>  this pseudo is dead, thus clobbering the pseudo.
>>  Conclusion: such a pseudo must not go in a hard
>>  reg.  */
> 
> I can't argue with anything in that comment, other than the conclusion. :-)
> It's not the compiler's job to implement the setjmp/longjmp save/restore.
> Maybe Kenny was working around a problem with some target's buggy setjmp
> and spilling everything "fixed" it?

The only observable difference I can see between a variable that has been
spilled to memory versus one that is assigned to a non-volatile hard reg
is if it is modified between the setjmp and the longjmp.  In the case
where the variable is spilled to memory, the "new" updated value is the
value you _may_ see on the return from setjmp (the return caused by the
call to longjmp), whereas if it is assigned to a non-volatile register,
then you _will_ see the "old" value that was saved by the setjmp call.
I say _may_ see above, because there are cases were we might not store
the "new" updated value to memory, even if we've spilled the pseudo.
Examples would be spill code optimization, or the variable has been
broken into separate live ranges/pseudos. etc. etc.  I guess I can even
think of cases where we could see both "old" and "new" values of a
variable.  Think of a variable that has been spilled/split like below:

a =  [start of live range, a assigned to non-volatile reg]
spill store a
...
setjmp()
...
1)  ... = ... a ... [end of live range]
... [a not assigned to a reg in this region]
spill load a[start of live range]
2)  ... = ... a ... [end of live range]
...
if (...)
   a =   [start of live range]
3) spill store a[end of live range]
... [a not assigned to a reg in this region]
longjmp()


On return from setjmp (the return caused by the call to longjmp),
the use of "a" at "1)" will use the non-volatile hard register
that was saved by the initial call to setjmp, so it will see the
"old" value of "a".  However, since the use of "a" at "2)" loads
the value from memory, it will use the "new" value stored by
the spill load at "3)"!

That said, the comment above only talks about variables that do not
change between the setjmp and the longjmp and in that case, you will
see the same "old" value (which is the only value, since it wasn't
modified) regardless of whether it was spilled or not.

What does ANSI (or any spec) say about what should happen to variables
that are modified between the setjmp and longjmp calls?  Maybe all bets
are off, given the example above, since even spilling a variable live
across a setjmp can still lead to strange behavior unless you don't
allow spill/split optimization and I don't think we'd want that at all.

Peter

Getting into C++ Downloading gcc.

[Ray McAllister]

Hi, I'm totally blind. I do most of my programming in BASIC, but I use C++
now and then, actually, for drawing fractals.  I code graphics.  I've been
using Dev-C++ because it's the only thing I can find compatible with my
screen reader.  I don't like how I can't set up a char array bigger than
1400 by 1400  as I might want to make a fractal bigger than that.  I have
the computer fill an array with the fractal data for colors, and then it
writes a bitmap file with the data and I can access that through BASIC or
just show it to a friend.  All Dev-C lets me do for array size is 1400 by
1400 in an array, and that's using chars.  I'd use Booleans, but I need to
include color data for each pixel.  I wonder if GCC would be better with
that.  I also need to knowk, please, how and where to download GCC, the
latest version.  I'm not finding info on that.  In addition, when I run the
dev-c++ programs from bASIC, a window comes up on the screen saying so. Is
there a way, in GCC, to prevent that? 

 

Thanks, 

Ray McAllister. 

 

Re: gdb 8.x - g++ 7.x compatibility

[Daniel Berlin]

Again, please don't do this.
As you can see (see Tom Tromey's email), others have a use to go between
vtable types and the types they are attached to.
We should be getting away from linkage names, not going further towards
them.
There are a bunch of gdb bugs this won't solve, but adding an extension
(like tom did for rust) to go between vtable types and concrete types will
solve *all* of them, be *much faster* than what gdb does now, and have
basically *no* space increase at all.

Meanwhile, i can hand you binaries where the size increase is in the
hundreds of megabytes to gigabytes for adding linkage names.



On Fri, Mar 2, 2018 at 3:06 PM, Roman Popov  wrote:

> Ok, sounds reasonable. In case of debugger we are indeed "linking" RTTI
> name with name in debuginfo.
>
> I've checked LLVM docs, they generate Debuginfo from LLVM "Metadata", and
> metadata for types already contains mangled names in "identifier" field:
> https://llvm.org/docs/LangRef.html#dicompositetype . So it should not be
> hard to propagate it to object file.
>
> I will ask on LLVM maillist if they can emit it.
>
>
> 2018-03-01 13:03 GMT-08:00 Jason Merrill :
>
> > On Thu, Mar 1, 2018 at 3:26 PM, Andrew Pinski  wrote:
> > > On Thu, Mar 1, 2018 at 12:18 PM, Roman Popov 
> wrote:
> > >> Is there any progress on this problem?
> > >>
> > >> I'm not familiar with G++ , but I have little experience with LLVM.  I
> > can
> > >> try make LLVM emitting mangled names to DW_AT_name, instead of
> demangled
> > >> ones.
> > >> This way GDB can match DW_AT_name against RTTI. And for display it can
> > >> call  abi::__cxa_demangle(name, NULL, NULL, &status), from #include
> > >> .
> > >>
> > >> Will it work?
> > >
> > >
> > > Reading http://wiki.dwarfstd.org/index.php?title=Best_Practices:
> > > the DW_AT_name attribute should contain the name of the corresponding
> > > program object as it appears in the source code, without any
> > > qualifiers such as namespaces, containing classes, or modules (see
> > > Section 2.15). A consumer can easily reconstruct the fully-qualified
> > > name from the DIE hierarchy. In general, the value of DW_AT_name
> > > should be such that a fully-qualified name constructed from the
> > > DW_AT_name attributes of the object and its containing objects will
> > > uniquely represent that object in a form natural to the source
> > > language.
> > >
> > >
> > > So having the mangled symbol in DW_AT_name seems backwards and not the
> > > point of it.
> >
> > If we add the mangled name, which seems reasonable, it should be in
> > DW_AT_linkage_name.
> >
> > Jason
> >
>