GDB - map address to line and column in source code - gdb

Both gcc and clang have option -gcolumn-info, which is described this way:
Emit location column information into DWARF debugging information, rather than just file and line.
I have compiled my binary with this option. Now I have address of some instruction and want to translate it back to source file, line number and column. Is there a way to do it in gdb? Is there some other tool that can extract this information?
I know that I can use info line *0xabcd1234 in gdb to get the source file and line corresponding to that address, but it does not show the column.

Answering my guestion, I found one way to get the information using lldb and image lookup command:
(lldb) image lookup --address 0x134adc
Address: libaaa.so[0x0000000000134adc] (libaaa.so.PT_LOAD[0]..text + 1030908)
Summary: libaaa.so`test() + 272 at test.cpp:1842:124

Related

How to examine bytes in gdb without printing labels?

GDB is trying to be helpful by labeling what I believe are global variables, but in this case each global is more than 0x10 bytes and so the second part of the variable is printed on the next line, but with an offset added to its label, which throws off the alignment of the whole printout (generated by executing x/50wx 0x604130):
Is there a command to disable these labels while examining bytes?
Edit: to be more specific, I would like to printout exactly what is shown in the screenshot, just without the <n1> / <n1+16> labels that are throwing off the alignment of the columns
Is there a command to disable these labels while examining bytes?
I don't believe there is.
One might expect that set print symbol off would do it, but it doesn't.
The closest I can suggest is this answer.

Create motorola s-record with fixed size length

Because I have to use a third-party bootloader which cannot handle varying lengths of lines in an SREC file, I need a way to instrument objcopy to create a SREC file, where every S1 line has the same lengths (if no info from ELF file is provided, it should be filled with FF).
We can assume that the address increments are consistent, so we do not jump higher in addresses than our specified line length. So we do not need to create in-between lines with all FF e.g.
I found out about --srec-len but this only sets the maximum length size.
I would need something that sets a fixed length size, is there something I can use?
A possible solution would be also to transform the earlier generated SREC file from objcopy with a (third-party) tool
You can try the srec_cat utility to do this. Following is an example command.
"srec_cat long.srec −o short.s19 −line-length=46"

How to check max number of file open-wirte-close operations per second in ubuntu

Having some files on disk. The files have fixed size lines with the following format:
98969547,1236548896,1236547899,0a234505,1478889565
which 0a234505 is an IP Address in hex format.
I should open a file, read on line of the file and found the IP address. Then, create a directory on disk (if not exists) with the same name as IP Address and create a file witch holds the line under that directory.
The file name is today date e.g. 2017-02-09. If the directory and the and its file is created previously, simply append the corresponding line to the end of the file.
My files contains too much lines e.g. 100000 or greater, so this steps must be repeated for all lines.
My requirement is to process one files with 100000 lines in one second.
so what i need to understand is what is the maximum number of file open-wirte-close operations per second in ubuntu 16.04?
if the answer does not satisfy my requirement, How should I properly do this?
so its better to say if the OS limitation does not allow me to do such a huge amount of open-write-close operations, is there any second way to do this?
Programming language: c++
OS: ubuntu-16.04 4.4.0-62-generic

SAS "successfully assigned from logical server" vs "successfully assigned as follows"

As I was looking through a log file from
D:\SAS\XXX\Lev1\SASMain\BatchServer\Logs
I saw these two lines
NOTE: Libref TESTLIB successfully assigned from logical server.
NOTE: Libref TESTLIB was successfully assigned as follows:
Engine: XXXX
Physical Name: XX.XXX.XXX.XX
What is the difference between or meaning behind these two lines?
The first line tells you that the library has been assigned as a pre-assigned library from metadata. If you look at SAS Management Console>Data Library Manager>TESTLIB>properties>Options>Advanced Options>"Library is Pre-Assigned". If this checbox is ticked, you will see the first line, given that the user has "Read Metadata" permissions on the library.
The second line comes if the library is explicitly assigned in the code. DI Studio will create libname statements in the code if the library is not pre-assigned.
Assuming that you found the two lines right next to each other:
The first line is telling you that SAS encountered no problems trying to assign the libref TESTLIB. If you tried to assign a libref to a non-existent folder / server, or you didn't have the necessary access (etc...) you'd get an error message instead of this line.
The second line is telling you a bit more about the libref that was assigned. In your case this includes the IP address of the server and SAS libname engine used. Depending on the value of XXXX, it's possible that in this case you're connecting to a different DBMS.

rrdtool xport - limit on DEFs

I have a script that generates command line invocations of rrdtool xport based on input provided in a domain specific language. This works well, until the number of DEFs in the command line exceed a certain number - it seems to be around 50. At that point the command simply returns without any output or error information.
Is there a limit on the number of DEFs in rrdtool export? If so, then can it be raised or circumvented?
The issue turned out to be the character limit on the command line sent to the shell via Python's os.system method call. The issue can be worked around by creating a temporary executable script, writing the command line to the script and executing it.