Re: gdb-6.4: is not handling input 'q' properly
Hi RAM, The following result was the effect of "info threads" command Since this is GDB bug that you are reporting, please could you either send it to the GDB mailing list at <[EMAIL PROTECTED]> or else fill in a bug report at: http://sourceware.org/gdb/bugs/ Thank you. Nick - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-am33-list] Re: Compiler for mn10300?
Hi Adrian, What are the plans regarding getting a plain upstream gcc compiling the kernel? One of the things on my plate is to get the -mno-mem-funcs patch contributed upstream. (Along with a lot of other pending AM33 patches, such as the support for the AM34 processor). As it happens MEI have just opened an issue with regard to -mno-mem-funcs, so any pushing of the patch will have to wait until that is resolved. Cheers Nick -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Control Dependencies vs C Compilers
Hi Guys, OK, so playing the devils advocate here... > Mostly I just want the compiler people to say they'll guarantee the > behaviour if we do 'X'. If 'X' happens to be 'any dynamic branch headed > by a volatile load' that's fine by me. Is a compiler hack really the right way to go here ? After all, if you do get this feature added it will make it harder to compile the kernel with other compilers (*cough LLVM cough*), or older versions of gcc. Plus code like this is often subject to very aggressive optimization and all it takes is one bug in the compiler implementation and you lose the gains you were trying for. My suggestion as an alternative is to use assembler instead. That way you can guarantee that you get the instructions you want in the order that you want them. It should be fairly straightforward to create a macro or inline function that contains the necessary code and this can be done once and then used wherever the functionality is required. Cheers Nick
Re: linux tooling mailing list
Hi Guys, >> linux-toolcha...@vger.kernel.org > Created. I have been able to subscribe to this list, so it looks like thunderbirds are go... Cheers Nick
Re: Kernel build error on BTFIDS vmlinux
Hi Mark, > Adding Nick, the binutils maintainer, so we can make sure > binutils/elfutils agree on some ELF section compression corner case. Thanks for doing this. > But it would obviously be better if that wasn't necessary. So I'll try > to fix libelf so that if it fixes up the alignment when reading the > compressed data, it also does that when writing out the data again. But > that would only help for a new version of elfutils. > > So it would be nice if binutils ld could also be fixed to write out > compressed sections with the correct alignment. OK, I will look into doing this. By any chance is there a small test case that you are using to check this behaviour ? If so, please may I have a copy for myself ? Cheers Nick
Re: Kernel build error on BTFIDS vmlinux
Hi Guys,
>> so when I take empty object and compile like:
>>
>> $ echo 'int main(int argc, char **argv) { return 0; }' | gcc -c -o ex.o -g
>> -gz=zlib -x c -
>> $ ld -o ex --compress-debug-sections=zlib ex.o
Thanks Mark. I have now created a binutils PR for this bug, and I am looking
into a fix:
https://sourceware.org/bugzilla/show_bug.cgi?id=26428
Cheers
Nick
Re: [PATCH] Makefile: support compressed debug info
Hi Nick, > + Nick, H.J. > I'm unfamiliar with the git tag conventions of binutils. Does a patch > that landed in 2.25.51.0.4 mean it shipped in the official 2.25 > release, or 2.26 release? Specifically, commit 19a7fe52ae3d. 2.26. The convention is that a released form of the binutils has a version number of X.XX or possible X.XX.N. The current mainline development sources have a version of X.XX.50 where X.XX is the latest release. (So the current mainline sources are version 2.34.50). When a release happens the XX value is incremented by one as part of the release process, and the .50 is dropped. (So the next binutils release will be 2.35). So 2.25.51.0.4 is a development version which will then have been released as binutils 2.26. Cheers Nick
Re: [PATCH] perf tools: Filter out hidden symbols from labels
Hi Arnaldo, >> there were no objections for rfc, sending patch > > I don't see a problem, Nick, can you provide an Acked-by, or better yet, > a Reviewed-by so that Jiri can collect in this patch and I can push it > to perf/urgent? Sorry - I do not think that I have the authority to do that. I am not a perftools maintainer (or a kernel maintainer). For what it is worth the patch does look good to me, but I think that a real maintainer needs to approve it. Cheers Nick
Re: [PATCH] perf tools: Filter out hidden symbols from labels
Hi Arnaldo, >> Sorry - I do not think that I have the authority to do that. I am not a >> perftools maintainer (or a kernel maintainer). For what it is worth the >> patch does look good to me, but I think that a real maintainer needs to >> approve it. > > Ok, I was more thinking about this part of > Documentation/process/submittingpatches.txt: > > > Acked-by: is not as formal as Signed-off-by:. It is a record that the acker > has at least reviewed the patch and has indicated acceptance. Hence patch > mergers will sometimes manually convert an acker's "yep, looks good to me" > into an Acked-by: (but note that it is usually better to ask for an > explicit ack). > > > But its ok, if you still don't feel this should be added, I'll just > leave a Cc: you, ok?
Re: [PATCH] perf tools: Filter out hidden symbols from labels
Hi Arnaldo, [oops- hit send by mistake...] >> Sorry - I do not think that I have the authority to do that. I am not a > Ok, I was more thinking about this part of > Documentation/process/submittingpatches.txt: > > > Acked-by: is not as formal as Signed-off-by:. It is a record that the acker > has at least reviewed the patch and has indicated acceptance. Hence patch > mergers will sometimes manually convert an acker's "yep, looks good to me" > into an Acked-by: (but note that it is usually better to ask for an > explicit ack). > > > But its ok, if you still don't feel this should be added, I'll just > leave a Cc: you, ok? Yes - this would be fine with me. Cheers Nick
Re: [RFC] perf tools: Filter out hidden symbols from labels
Hi Jiri, > When perf is built with annobin plugin (RHEL8 build) extra symbols > are added to its binary: A bit of background for those wondering why annobin is creating these symbols: Annobin is a plugin for gcc that records data about how object file were built. It is specifically designed to be able to cope with files that are built using multiple different sets of optimization options. (Eg because of #pragma directives or function specific optimization attributes). It generates notes to cover each compiled region of code, and it needs the symbols in order to be able to determine exactly which areas in a linked binary were compiled with which options. In the course of developing this plugin I encountered various problems with tools not expecting to find extra symbols in a binary. Hence I made the symbols local, hidden and with no type. It was the best I could do to say "ignore these symbols - they are not meant to be seen by anyone but annobin". > + elf_sym__visibility(sym) != STV_HIDDEN; Just to be awkward, if you are going to ignore STV_HIDDEN symbols then you should probably also ignore STV_INTERNAL ones as well... Annobin does not generate them, but you never know, one day some other tool might create some. Cheers Nick
Re: [RFC] perf tools: Filter out hidden symbols from labels
Hi Guys, >> Humm, it would be nice for perf annotate to show those options when one >> navigates the annotation, Usually the command line options can also be found in the debug info for the executable. Assuming it has not been stripped, of course. One of the advantages of the annobin strategy of using ELF notes is that these are not stripped from executables... Unfortunately the annobin notes will probably not be very helpful as they only record a minor subset of the typical gcc command line options. (Specifically: -O, -g, -D_FORTIFY_SOURCE, -D_GLIBCXX_ASSERTIONS, -fcf-protection, -fpic (and variants), -fshort-enum, -fstack-clash-protection, -fstack-protector, -mstackrealign, -fexceptions). >> Is there any library that gets those >> annotations and put them in some linked list that we could use in >> tools/perf/? Sorry - no such library exists. > If it's just an ELF note, we could parse it directly. > https://developers.redhat.com/blog/2018/02/20/annobin-storing-information-binaries/ Exactly - and what a great blog author that person is ... :-) Cheers Nick
Re: [RFC] perf tools: Filter out hidden symbols from labels
Hi Arnaldo, >> Unfortunately the annobin notes will probably not be very helpful as they >> only record a minor subset of the typical gcc command line options. >> (Specifically: -O, -g, -D_FORTIFY_SOURCE, -D_GLIBCXX_ASSERTIONS, >> -fcf-protection, -fpic (and variants), -fshort-enum, >> -fstack-clash-protection, >> -fstack-protector, -mstackrealign, -fexceptions). > > Humm, is -fno-omit-frame-pointer there by any chance? :-) Not at the moment, although it could be added. All of the options mentioned in the above list are recorded because they have an impact on the security hardening of the binary. Other options are ignored because, at least for now, they have no security implications. Cheers Nick
Re: [RFC] perf tools: Filter out hidden symbols from labels
Hi Arnaldo, >>> Humm, is -fno-omit-frame-pointer there by any chance? :-) > Would be interestint to have that info, as we could hint the user that > backtraces should be done with something else than '--call-graph fp' :-) OK, well I have added the feature to annobin 8.67, now in Fedora rawhide. Unfortunately it will take a while before the information actually gets into binaries, since the new data is only recorded when a package is rebuilt. So basically you are looking at Fedora 30 at the earliest. If you want to see the plugin in action, build something on a rawhide system (or a mock chroot) using the gcc command line option -fplugin=annobin. (Make sure that you have annobin-8.67 installed). Then once the binary is built run "readelf --wide --notes | grep omit" to see the omit-frame-pointer notes. Cheers Nick
Re: [RFC PATCH 0/3] Salted build ids via linker sections
Hi Laura, > This is an implementation of the counter proposal. If an environment variable > is set, that value gets added as a .comment section to the necessary binaries. This is not really my purview but ... can I just say that I really do not like using environment variables to control build behaviour. It makes reproducing a build much harder. Especially when you are trying to reproduce a bug report from a user who does not even know that the environment variable exits. Cheers Nick
