[ 
https://issues.apache.org/jira/browse/NETBEANS-2000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17087271#comment-17087271
 ] 

Scott Furry commented on NETBEANS-2000:
---------------------------------------

It's not the type of project settings. Shouldn't have to explicitly identify 
the end binary in the project settings. That's what is being suggested in the 
workaround. As for cleaning, if the end binary is in an out-of-source, CMake 
build folder and one clicks clean then run, Netbeans would complain about not 
finding the missing binary. Again, explicitly hard-coding the binary in the 
project settings is bad.

> PIE executables not recognized as executables
> ---------------------------------------------
>
>                 Key: NETBEANS-2000
>                 URL: https://issues.apache.org/jira/browse/NETBEANS-2000
>             Project: NetBeans
>          Issue Type: Bug
>          Components: debugger - Code
>    Affects Versions: 9.0, 10.0
>            Reporter: Johan Persson
>            Priority: Minor
>
> All major Linux distributions now (e.g Debian, Fedora. Ubuntu, OpenSuSE) 
> configure gcc with "{{--enable-default-pie}}" which will create Position 
> Independent executables by default (to support DEP/ASLR)
> By default PIE executables will identify themselves on Linux as:
> {{ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked}}
> This will be reported as ELF type ET_DYN
> However Netbeans does not recognize shared objects as executables and most 
> likely identifies them as a shared library. This means it is impossible to 
> use the debugger with C/C++ code since you cannot select an executable to run 
> the debugger on.
> For Netbeans to see a file as an ELF executable it must be of type
> {{ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked}}
> This will be reported as ELF type ET_EXEC
> Now, there is an easy workaround and that is to pass the options
> {{-fno-pie -no-pie}}
> to gcc when compiling (or the corresponding to say clang) to create 
> "old-style" executables. For security reason that is of course not 
> recommended for production code.
> Since there is a simply workaround and the fact that v10 does not yet 
> officially support C/C++ I have marked this down as "minor" but it is a low 
> hanging fruit to fix since it only requires identifying the code that 
> determines file type and include shared objects as allowable executables.
> Once C/C++ once again is officially supported it is of course vital that this 
> is fixed.
>  
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Reply via email to