But when we try to parse the abstract origin on our own it gives us
the one in the same file, which is 0. Is it because we should look into the
form of the DW_AT_abstract_origin? In this case seems to be the GNU_ref_alt,
correct?
Regards,
Sasha
From: Mark Wielaard
Sent: Wednesday, N
Hi,
we are currently dealing with multiple separate debug files, the normal
stripped ones put in .debug/ folder and now the ones generated by DWZ and put
into .dwz/ folder.
When loading a normal stripped debug files who has a dwz file, I saw the same
DIE (same id) twice with different data. Woul
Wednesday, June 10, 2020 6:33 AM
To: Sasha Da Rocha Pinheiro ;
elfutils-devel@sourceware.org
Subject: Re: location list
Hi Sasha,
On Tue, 2020-06-09 at 16:38 +, Sasha Da Rocha Pinheiro via
Elfutils-devel wrote:
> I am now trying to design the changes needed to be done in Dyninst.
> So f
: Sasha Da Rocha Pinheiro ;
elfutils-devel@sourceware.org
Subject: Re: location list
Hi Sasha,
On Sat, 2020-06-06 at 00:30 +0000, Sasha Da Rocha Pinheiro wrote:
> As you can see the following variables have distinct locations:
> [ 81] variable abbrev: 5
>
0] const4u 65537
[ 5] breg0 0
[ 7] minus
[ 8] stack_value
Sasha
From: Sasha Da Rocha Pinheiro
Sent: Tuesday, June 2, 2020 1:12 PM
To: Mark Wielaard ; elfutils-devel@sourceware.org
Subject: Re: location list
Well, I have been trying to use the Dwarf
in .debug_loc. Where
clearly for this variable, the location list (sec_offset) is at [4a] of
that section.
Maybe I am using the offset or the basep wrongly?
Sasha
From: Mark Wielaard
Sent: Tuesday, June 2, 2020 12:19 PM
To: Sasha Da Rocha Pinheiro ;
elfutils-devel@sourceware.org
Su
Hi all,
I am trying to parse a location list given as an sec_offset.
How do I get this offset value that points to .debug_loc so I can call
dwarf_getlocations()?
Should I pass this offset as the second parameter of this call?
Sasha
W_LNS_fixed_advance_pc
SPECIAL(1, 0)
DW_LNS_fixed_advance_pc
SPECIAL(1, 0)
DW_LNS_fixed_advance_pc
DW_LNE_end_sequence
And that does not give us range end. Am I correct? Can we make any assumptions
for it?
Regards,
Sasha
From: Mark Wielaard
Sent: Thursday, September 12, 20
Hi all,
how do we get the line info range end address for a given line and file?
For instance, gdb adds 2 breapoint to:
(gdb) b /g/g90/devkota1/LULESH/lulesh.cc:233
Breakpoint 1 at 0x4060a0: /g/g90/devkota1/LULESH/lulesh.cc:233. (2 locations)
(gdb) i b
Num Type Disp Enb Address
roblem here is that I need to assess with
the updated headers where to place a new header. It seems I can't call
elf64_newphdr again on the new_elf handle.
Sasha
From: Sasha Da Rocha Pinheiro
Sent: Tuesday, June 25, 2019 5:09 PM
To: Mark Wielaard; Frank Ch. Eigler
Cc: elf
What happens if I call elf64_newphdr() on the same Elf * but with different
size_t __cnt?
What happens to the previous headers?
Sasha
From: Mark Wielaard
Sent: Tuesday, June 25, 2019 12:56:04 AM
To: Sasha Da Rocha Pinheiro; Frank Ch. Eigler
Cc: elfutils-devel@sourceware.org
Oh, of course, that might be it.
Do you know if when it's open with write permission, changes will be mapped
back to the file?
Thanks,
Sasha
From: Frank Ch. Eigler
Sent: Monday, June 24, 5:06 PM
Subject: Re: Elf64_Phdr
To: Sasha Da Rocha Pinheiro
Hi all,
If I have a Elf64_Phdr, why can't I straight change its elements, like, I'm
getting seg fault when trying to do:
(see gdb output)
... received signal SIGSEGV, Segmentation fault.
...
957 oldPhdr->p_vaddr = 0x1235;
(gdb) p/x oldPhdr
$11 = 0x3ffb4bf0040
(gdb) p/x *oldPhdr
$12 = {p_
0x970
restore r30 (reg30)
restore r29 (reg29)
def_cfa r31 (reg31) at offset 0
nop
nop
nop
nop
nop
nop
nop
From: Mark Wielaard
Sent: Friday, May 3, 2019 4:09 PM
To: Sasha Da Rocha Pinheiro
Cc: elfutils-devel@sourceware.org
Subject: Re: Dwarf_Op
On
alive. */
Why simple expression can only have 3 operations? (since Dwarf_Op ops_mem[3])
And what's an arbitrary Dwarf expression? What's a non-arbitrary?
Regards,
Sasha
From: Mark Wielaard
Sent: Wednesday, May 1, 2019 6:02 PM
To: Sasha Da Rocha Pinheiro
Cc: elfutils-devel@sourceware.
ay, April 27, 2019 12:57 PM
To: Sasha Da Rocha Pinheiro
Cc: elfutils-devel@sourceware.org
Subject: Re: Dwarf_Op
On Fri, Apr 26, 2019 at 04:48:49PM +, Sasha Da Rocha Pinheiro wrote:
> The output from dwarfdump:
>
> < 5><0x00400918:0x00400974> 0>
>
>
e_register.
Even though, the member number is of unsigned int type with signed encoded
values. Am I correct?
Sasha
From: Mark Wielaard
Sent: Friday, April 26, 2019 3:20 AM
To: Sasha Da Rocha Pinheiro; elfutils-devel@sourceware.org
Subject: Re: Dwarf_Op
Hi Sasha,
On Thu, 2019-04-25 at 23:5
Hi all,
I have a Dwarf_Op object whose member "number" has size of 8 bytes.
Its value although is 0xFFE8.
Shouldn't it be 0xFFE8 instead?
Since it means an offset, for the current operation, shouldn't it be of a
signed integer type instead of unsigned?
Regards
Sasha
I built again in another folder, version .0175, and added that to
LD_LIBRARY_PATH. And it seems to work fine.
Somehow the version we build with Dyninst cmake is not working.
Thanks
Sasha
From: Mark Wielaard
Sent: Tuesday, February 12, 2019 2:57 PM
To: Sasha Da Rocha Pinheiro
Cc: elfutils
I was using elfutils version 0.175, since we download the lastest.
But after moving back to 0.173, this problem disappeared. So, some update after
0.173 broke this.
Sasha
From: Sasha Da Rocha Pinheiro
Sent: Tuesday, February 12, 2019 12:49 PM
To: Mark Wielaard
Cc: elfutils-devel
No, because we need at least 0.173 and the system version is 0.165.
From: Ben Woodard
Sent: Tuesday, February 12, 2019 12:39 PM
To: Sasha Da Rocha Pinheiro
Cc: Mark Wielaard; elfutils-devel@sourceware.org
Subject: Re: unknown error after dwarf_cfi_addrframe()
Does it work at all if you use
paradyn/development/sasha/dyninst/build.dir/elfutils/src/LibElf/libebl/eblopenbackend.c:329
329 if (h == NULL)
(gdb)
From: Sasha Da Rocha Pinheiro
Sent: Tuesday, February 12, 2019 11:57 AM
To: Mark Wielaard
Cc: elfutils-devel@sourceware.org; Ben Woodard
Subject: Re: unknown error after dwarf_cf
Not working even after adding the directory to libebl_*.so to LD_LIBRARY_PATH.
default_abi_cfi is still called returning -1.
Sasha
From: Mark Wielaard
Sent: Tuesday, February 12, 2019 2:09 AM
To: Sasha Da Rocha Pinheiro
Cc: elfutils-devel@sourceware.org; Ben Woodard
Subject: Re: unknown
* ones are.
It seems that the library is being compiled using BACKEND as default and not
catching the correct architecture (?).
Sasha
From: Sasha Da Rocha Pinheiro
Sent: Thursday, February 7, 2019 4:57 PM
To: elfutils-devel@sourceware.org; Mark Wielaard
Subject: unknown error after
It's not working but I'm fixing it.
We don't use Elfutils to find the corresponding separate debug info. It was
already implemented by searching the gnu_debuglink section and getting the info.
Sasha
From: Mark Wielaard
Sent: Tuesday, September 18, 2018 6:36 AM
To: Sasha Da
Hi,
I have found a bug in Dyninst related to the fact that dwarf_begin_elf() won't
create a (Dwarf *) handle given a stripped binary which contains the section
".eh_frame".
This section is sometimes generated to the detriment of ".debug_frames", which
is omitted, while all info about frames are
riday, June 29, 2018 8:24 PM
To: Sasha Da Rocha Pinheiro; elfutils-devel@sourceware.org
Subject: Re: dependency
On Sat, 2018-06-30 at 00:49 +0000, Sasha Da Rocha Pinheiro wrote:
> Hi,
> is there a reference for the last stable version of Elfutils?
>
> Currently we set the following
> Each elfutils release is "stable". Are you looking for
> a fixed URL for the most recent release?
Yes, that's what I meant.
Sasha
From: Frank Ch. Eigler
Sent: Friday, June 29, 2018 8:12 PM
To: Sasha Da Rocha Pinheiro
Cc: elfutils-devel@sourceware.org
Subject: Re: depe
Hi,
is there a reference for the last stable version of Elfutils?
Currently we set the following path in our cmake configuration to download and
compile Elfutils as a dependency for Dyninst, but lately there has been some
important modifications, and I think it would be nice to have a reference
Wielaard
Sent: Tuesday, June 5, 2018 6:27:17 AM
To: Sasha Da Rocha Pinheiro; elfutils-devel@sourceware.org
Subject: Re: dwarf_next_cfi returns -1
On Mon, 2018-06-04 at 16:16 +, Sasha Da Rocha Pinheiro wrote:
> We had a case where dwarf_next_cfi returns -1 but the offset does not
> upda
Hi,
We had a case where dwarf_next_cfi returns -1 but the offset does not update,
as we should expect by the comment:
330 On errors, returns -1. Some format errors will permit safely
331 skipping to the next CFI entry though the current one is unusable.
332 In that case, *NEXT_OFF wi
ld like to know about this mixed FDEs possibility.
Sasha
From: Mark Wielaard
Sent: Thursday, May 24, 2018 11:28 AM
To: Sasha Da Rocha Pinheiro; elfutils-devel@sourceware.org
Subject: Re: dwarf_begin_elf() won't create handle without .debug_* sections
On Wed, 2018-05-23 at 20:09 +0000, Sas
Hi all,
I have some binaries that do not have .debug_* sections but have .eh_frame and
.gcc_except_table.
Looking at:
https://sourceware.org/git/?p=elfutils.git;a=blob;f=libdw/dwarf_begin_elf.c;hb=144b73c49acf3ed894e4635aedb9b0d1208ade2e#l50
it seems that dwarf_begin_elf() will not create a
Hi,
I have noticed that when we compile out-of-source, the paths returned from
libdw are gonna be relative. Otherwise, they show up as full path.
Have you noticed it?
Regards,
Sasha
Hi,
is it possible to read contents of .debug_line section without the presence of
a .debug_info section?
We have CUDA binaries being generated with only .debug_line, and we wish to use
that. Is it possible to do that with libdw?
If not, any ideas of how to construct a minimum .debug_info in o
Hi, how do I get FDE augmentation data?
Yes, that's what I am trying to do right now.
Try/catch blocks or exception handling is the right term I guess.
From: Mark Wielaard
Sent: Monday, July 17, 2017 12:48 PM
To: Sasha Da Rocha Pinheiro
Cc: elfutils-devel@sourceware.org
Subject: Re: Dwarf_FDE (libdw)
On Mon, Jul 17, 2017
rom: Mark Wielaard
Sent: Monday, July 17, 2017 8:04 AM
To: Sasha Da Rocha Pinheiro
Cc: elfutils-devel@sourceware.org
Subject: Re: File index given line (libdw)
On Mon, 2017-07-17 at 04:10 +, Sasha Da Rocha Pinheiro wrote:
> [Resending cause it seems it didn't go]
Probably because
I need FDE augmentation data also.
Libdw doesn't do this, am I correct?
From: Mark Wielaard
Sent: Monday, July 17, 2017 8:28:56 AM
To: Sasha Da Rocha Pinheiro
Cc: elfutils-devel@sourceware.org
Subject: Re: Dwarf_FDE (libdw)
On Mon, 2017-07-17 at 04:12 +, Sasha Da Rocha Pinheiro
2017 4:30 PM
To: Sasha Da Rocha Pinheiro
Cc: elfutils-devel@sourceware.org
Subject: Re: Dwarf_FDE (libdw)
On Sat, Jul 15, 2017 at 01:00:04AM +, Sasha Da Rocha Pinheiro wrote:
> I did not understand how to get the augmentation_data of a FDE.
> Could anyone explain me?
Dwarf_FDE is
cessary search.
"Why is it important to match this particular filename to one in the vector you
created from the Dwarf_Files?"
Because Dyninst needs to make its own parsing and fill its own data structures
in the most efficient way.
From: Mark Wielaard
Sent: Saturday, July 15, 201
Hi Mark,
>But why do you want to do that?
Performance and save memory space.
>If we would add int dwarf_line_index (Dwarf_Line *line, size_t *idx) how
>exactly would you use it?
I would get idx and save it in my data structure so I don't have to save the
file name repeatedly for each line.
Hi,
I did not understand how to get the augmentation_data of a FDE. Could anyone
explain me?
Also, is the start and end of Dwarf_FDE to be used as [initial_location,
initial_location+address_range)??
Regards,
Sasha
typedef struct
{
/* Section offset of CIE this FDE refers to. This will never
has to be done for each line.
Instead, if I could get the file index in the array "struct Dwarf_Fileinfo_s
info", I wouldn't need to search.
From: Mark Wielaard
Sent: Thursday, July 13, 2017 4:11:09 AM
To: Sasha Da Rocha Pinheiro
Cc: elfutils-devel@sourceware.org
Subject: Re: F
Hi guys,
when we get the files given a Die and want to know the file given the line, the
only way to do this is comparing the return of dwarf_linesrc with the list of
filenames we had from dwarf_getsrcfiles?
Why can't we get the index of the file given the line? Just return the unsigned
int fil
45 matches
Mail list logo
